Seminario residenziale Museimpresa – Parma e dintorni (30 settembre – 1 ottobre 2011)

MUSEO E ARCHIVIO 2.0 – Social network e interattività per musei e archivi d’impresa

Pagina 1

Apps nel museo – qual i prospett ive? I l caso del MACRO

Alessandro Califano1

“…ci facciamo un App?”

“Perché no? Per me con ghiaccio…”

In tempi di “vacche magre”, con budget dedicati ai beni culturali – mostre “blockbuster” escluse –

sempre più ridotti e sponsor sempre più guardinghi, il fenomeno delle apps museali sembra da un

lato acquistare interesse e, dall’altro costituire la nuova frontiera per l’offerta di servizi ai musei.

“Farsi un’app” può diventare così la risorsa tanto cercata per promuovere la propria istituzione

museo in un quadro finanziariamente stagnante o, mai sia!, in recessione. “Proporre un’app”, d’altro

canto, significa – per un’impresa – cercare di accreditarsi come tecnologicamente vitale, innovativa

e – perché no? – à la page.

Siamo dunque in presenza di una nuova opportunità irrinunciabile? Della chiave di volta che

consentirà ad un settore da tempo asfittico di risorse ed opportunità di tornare a volare alto, di

acquisire nuovi pubblici e diversificare la propria offerta culturale? O si tratta invece di una nuova

moda, di un hype costoso e di utilità dubbia? Forse, per rispondere a questa domanda – niente

affatto secondaria, se consideriamo l’esigenza assoluta, come istituzione museale, di investire al

meglio le scarse risorse disponibili – dobbiamo fare un passo indietro.

Il mondo dell’IT (Information Technology) è costituito da un lato da quello che è definito hardware

e, dall’altro, di ciò che è detto software. In un’ottica museologica, potremmo rispettivamente parlare

di beni materiali (l’HW) e di patrimonio immateriale (il SW). A sua volta, il software può

concettualmente suddividersi da un lato in strumenti di programmazione e sistemi operativi e,

dall’altro, in software applicativo. Le apps (abbreviazione del termine applications, ovvero

“applicazioni”) sono un altro modo di chiamare il software applicativo.

Come definire, dunque, le apps? Probabilmente, sia sulla base di ciò che esse non sono, sia sulla

base di ciò che esse, invece, sono. Non sono linguaggi (cioè protocolli di comunicazione codificata

uomo/macchina), né sistemi operativi (i “motori”, cioè, che muovono i sistemi). Sono, invece,

strumenti che consentono ad uno o più utenti di “fare” cose con i dati – permettendo di visualizzarli,

modificarli, distribuirli e così via. Tuttavia, perché possano venire utilizzati, tali strumenti devono

tener conto di ciò che essi stessi non sono – e cioè dei linguaggi e dei sistemi operativi, nell’ambito

dei quali, e subordinatamente ad essi, si trovano ad operare. Non necessariamente uno strumento

costruito per funzionare nell’ambito di un determinato linguaggio o di un sistema operativo sarà

infatti utilizzabile anche in un altro.

Occorre, a questo punto, ricordare un vecchio aforisma relativo al mondo dei computer, che recita:

“Rubbish in – rubbish out” (potremmo renderlo con un “se immetti spazzatura, esce spazzatura”).

La qualità del risultato di uno strumento per fare cose con i dati (cioè di un’app), dipende in buona

parte anche dalla qualità dei dati stessi, cioè dal contenuto su cui vi intende operare. E, a questo

proposito – riconducendo la questione al mondo dei musei – occorre chiedersi, in particolare: chi

fornisce tale contenuto? Come lo fornisce? Perché lo fornisce? Con quali finalità?

E’ soltanto sulla base di risposte soddisfacenti a questi interrogativi, e tenendo a mente il quadro

generale precedentemente descritto, che potremo considerare – sulla base della consueta analisi di

costi e benefici – se l’app che ci viene proposta, o che può venirci in mente di sviluppare in ambito

museale, abbia o meno una propria validità. In particolare, dovremmo chiederci:

Seminario residenziale Museimpresa – Parma e dintorni (30 settembre – 1 ottobre 2011)

MUSEO E ARCHIVIO 2.0 – Social network e interattività per musei e archivi d’impresa

Pagina 2

• Si tratta di un software “proprietario” (sviluppato cioè da una determinata impresa e solo da

quella)? Di un software commerciale (sviluppato da una determinata impresa, ma secondo

standard condivisi, riproducibili anche da altri)? Di un software FOSS (free & open source

software, realizzato in condivisione e trasparenza, distribuito – in genere – gratuitamente)?

• Che livello di portabilità ha? E’ condivisibile – cioè – tra sistemi operativi e piattaforme

diverse (Linux, UNIX, MS Windows, Mac OS, ma anche – considerando i sistemi operativi

di apparecchiature mobili, quali ad esempio gli smartphone – Android, iOS, Symbian)?

• E’ trasparente, rispetto al sistema operativo ed anche rispetto agli altri software applicativi in

uso o installati? O costringe piuttosto a modificare alcuni dei parametri correntemente in

uso, al fine di poterlo utilizzare?

• Ha un ciclo di vita definito? In quanto tempo si prevede che divenga obsoleto, con il mutare

della tecnologia? Sono disponibili o previste versioni di aggiornamento? Si prevede che la

loro installazione richiederà operazioni particolari da parte dell’utente? Chi effettuerà una

eventuale manutenzione dell’applicazione nel corso della sua validità?

• L’applicazione ed i dati da essa derivabili sono condivisibili, riutilizzabili, integrabili con

altri dati o altre applicazioni? In particolare, tali dati sono riutilizzabili in un documento

redatto a posteriori con un’applicazione diversa, o che debba girare su di una diversa

piattaforma? Debbono rilanciarsi – pensiamo ad un social network, un wiki o un forum –

così come sono, o possono trasformarsi in un’opera derivata, integrandoli con altri elementi

non derivati dall’elaborazione dell’applicazione stessa?

• La condivisibilità va a scapito della privacy dell’operatore? Ed è o non è possibile scegliere

il livello di riservatezza preferito?

• Ed ancora, rispetto ai dati: si tratta di dati statici o modificabili? Vi è la possibilità, da parte

dell’utente (nel nostro caso, l’istituzione museo) di stabilire quali sono i dati più pertinenti,

quelli ripetitivi, quelli del tutto pleonastici? Chi ha il controllo di selezione e di immissione

dei dati? Si tratta di un procedimento congiunto impresa/museo, o di un “pacchetto” chiuso?

E’ rispondendo – e soprattutto: pretendendo una chiara risposta – a questi quesiti che può aversi una

griglia di valutazione delle apps. Più ancora: fissando dei diversi valori a ciascuna opzione (ed alla

rispettiva presenza o assenza di esse) si potrà avere un benchmarking della app presa in esame,

rispetto al massimo di appetibilità cui esse devono (ciascuna nel proprio ambito di utilizzo) tendere.

Potremmo così, tanto per fare un esempio parziale, ma concreto, stabilire i seguenti punteggi:

1. per il tipo di software: software proprietario, 0 punti; software commerciale, 1 punto;

software FOSS, 2 punti;

2. riguardo alla portabilità: 1 punto per ognuno dei sistemi operativi su cui l’applicazione può

girare (al massimo 7, sulla base di quelli più sopra elencati;

3. per la trasparenza: 2 punti, se l’app è del tutto trasparente rispetto a sistema operativo e altro

software installato; 1 punto, se richiede qualche aggiustamento minore; 0 punti, se richiede

aggiustamenti più complessi.

Avremmo così un punteggio ottimale pari a 11 (2+7+2), con il quale l’app proposta ad un museo

dovrà concretamente confrontarsi. Un punteggio medio od ottimo in ciascuna delle voci sarà – a

parità di contenuto, sua selezione e condivisibilità – una buona base di partenza per prendere in

considerazione la app stessa, mentre un punteggio scarso (o medio nel complesso, ma con picchi

Seminario residenziale Museimpresa – Parma e dintorni (30 settembre – 1 ottobre 2011)

MUSEO E ARCHIVIO 2.0 – Social network e interattività per musei e archivi d’impresa

Pagina 3

negativi in qualcuna delle voci) dovrebbe mettere in guardia da subito sull’opportunità di investirvi

tempo e risorse.

Nel caso della App museale, realizzata per il MACRO nel giugno di quest’anno, purtroppo, i dati di

un esame che prenda in considerazione un numero sufficiente di parametri, come quelli che sono

stati qui in precedenza descritti, non portano ad un benchmarking esaltante. L’app – scaricabile

dall’App Store di iTunes a partire dal 27 luglio 2011 – è disponibile soltanto per iPhone ed iPad,

piattaforme che utilizzano il sistema operativo Mac OS. Offre informazioni generali sul Museo

d’Arte Contemporanea di Roma, e qualche approfondimento (a pagamento) sulle mostre del ciclo

MACRO Summer 2011. Al di là delle affermazioni della società che ha realizzato il prodotto

(LOG607) – “particolarmente efficace e interessante la visione delle immagini” (passi per l’iPad,

ma a cosa mi serve focalizzarmi sulle immagini, se devo visualizzarle, quasi fossero thumbnails,

sullo schermo di un iPhone?) – si tratta in buona sostanza di un catalogo con qualche possibilità di

approfondimento multimediale, qualche indice, e la possibilità di prendere proprie annotazioni. La

possibilità di rilanciare le diverse pagine su social network sembra però effettuata più nel senso di

una promozione dell’app stessa, che non come occasione di rielaborazione, integrazione e

commento di dati di patrimonio comune.

Un’occasione sprecata, dunque? Forse non del tutto, se l’obiettivo era solo quello di realizzare un

catalogo per telefonia mobile delle iniziative realizzate per l’estate/autunno 2011 (ma lo si sarebbe

potuto realizzare più comodamente e adeguatamente in HTML su web, a costi senz’altro molto

minori, e per una serie di piattaforme molto più ampia). Sicuramente sì, se si voleva andare al di là

del nome trendy da conferire ad un prodotto non particolarmente innovativo e sostanzialmente

statico. Non basta mascherare un catalogo on-line dietro una definizione modaiola per trasformarlo

in un prodotto nuovo, né – tantomeno! – adeguato alle potenzialità interattive e innovative di un

Web 2.0. Siamo assai lontani, insomma, dalle potenzialità della locative art (Drew Hemment),

come descritte ad esempio, magistralmente, da William Gibson in “Guerreros” (Spook Country,

2007), applicate al mondo museale.

Ecco dunque, per ritornare al brevissimo dialogo che introduce la presente relazione, che lo scambio

di battute acquista un significato ben più profondo di quello immediatamente apparente. Se si

rammenta che il termine inglese per “ghiaccio” – ice – sta anche per Intrusion Countermeasures

Electronics, termine cyberpunk (utilizzato da Tom Maddox e, in seguito, da William Gibson –

ancora lui! – in Burning Chrome e Neuromancer, rispettivamente del 1982 e del 1984) riferito ai

sistemi di protezione dei dati, termine ripreso dalla IBM per il sistema di protezione di personal

computer e server denominato BlackICE (uscito di produzione a fine settembre del 2008), e dalla

sigla ICE dell’Information Concealment Engine, un sistema per la protezione dei dati tramite la loro

cifratura a blocchi (Kwan, 1997), possiamo reinterpretare così il dialogo: una app (per il museo o

altro utente) va bene, purché essa preveda (oltre alle molte altre cose descritte sin qui) anche una

efficace protezione dei dati trattati.

1 Alessandro Califano (1953), fotografo, museologo, orientalista – è Curatore presso il CRDAV (Centro

Ricerca e Documentazione Arti Visive) di Roma dal 1999, nonché Cultural Consultant dell'UNESCO in

Afghanistan. Membro della Canadian Museums Association, di ICOM Italia e di ICOMOS-UK, fa parte

della Commissione Nazionale Grandi Rischi per i Beni Culturali e, a partire dal 1981, si occupa di tecnologie

avanzate applicate ai musei e alle altre istituzioni del patrimonio culturale.