Tag Archives: OPAC

Il sito della biblioteca fa schifo

23 Apr

C’è un post che mi assilla da ormai un anno, che però non penso riuscirò mai a scrivere, sono troppo pigro e distratto. Credo mi abbia portato a una profonda disaffezione verso il mio lavoro e le biblioteche 😦

Allora facciamo che invece di raccontarvi come è iniziata, vi racconto l’ultimo episodio. Partendo da una domanda: ma voi, bibliotecari, sapete quanti visitatori ha il vostro sito?

Secondo me pochissimi, anche considerando solamente quelli potenziali.

Quando si diceva che gli OPAC fanno schifo, forse non si è parlato abbastanza dei siti delle biblioteche 😛 Anche se trovo molto importante che le biblioteche si siano sempre fatte promotrici di usabilità e accessibilità, spesso mi ritrovo di fronte ad una totale mancanza di sensibilità nei confronti di chi naviga e atterra sul sito della biblioteca.

Nel mio piccolo ho sempre pensato che la disattenzione nei confronti della propria presenza sul web derivasse dal ritrovare il proprio spazio affogato all’interno di un sito più grosso, magari un monolite della P.A. fatto di pagine immodificabili …chissà… sta di fatto che alla P.A., di quanti visitatori hanno i suoi siti, non gliene può fregare di meno. Dopotutto la qualità dei servizi non si misura da quanti visitatori abbiamo sul web, giusto?

Il punto non è che dovete diventare esperti di SEO, nè tantomeno dovete costruire voi i siti (anzi, evitate se non siete convinti di quello che fate). Però, dannazione, se decidete di avere uno spazio sul web dovreste essere in grado di: organizzarlo in maniera intelligente, interloquire con chi lo costruisce, pretendere che non vengano usati font come il Comic Sans, assicurarvi che i colori siano dignitosi, garantire il giusto equilibrio negli spazi, capire se sarete trovabili. Insomma preoccuparvi che gli utenti si sentano in uno spazio accogliente e non in una catapecchia abbandonata messa in piedi dopo un appalto farlocco.

Questo perchè purtroppo qualsiasi sito (o app) realizzato per le P.A. esce dalle comuni logiche che determinano il successo di un progetto web. Per i siti che non propongono servizi a pagamento, il successo deriva dal traffico che sono in grado di generare (o dal grado di retention). Da quanto ho capito, nel caso dei siti della P.A. l’importante è che il progetto corrisponda al prototipo definito. Tanto poi gli utenti sul sito devono andarci per forza se vogliono le informazioni, non è rilevante se il sito è fatto bene, basta che sia fatto.

Ecco, siccome magari non ve lo dicono abbastanza, volevo solo ricordarvi che il vostro sito fa schifo.

Un paio di note, dopo averci dormito sopra, che altrimenti mi sembra un discorso troppo sterile

A) Perché dovrebbe interessarvi di avere un sito fatto bene?

Mi vengono in mente almeno due motivi:

1) un bel sito, strutturato in maniera adeguata, è probabilmente la prima immagine di voi che date al mondo esterno. Fate una cosa bella e chi lo visita penserà che anche la biblioteca è curata allo stesso modo. Il sito fa parte della vostra identità tanto quanto la faccia del bibliotecario.

2) un sito fatto bene viene indicizzato meglio. Partendo dal presupposto che i servizi della biblioteca non sono adeguatamente conosciuti, essere trovati via web è una pubblicità permanente a costo zero. La quantità di persone che parteciperanno al vostro prossimo evento non sarà più determinata solo dalla quantità di manifesti e volantini sparsi per il comune, ma anche da quanto e come l’informazione risulterà visibile online.

B) Come intervenire per migliorare la situazione?

1) cercate di avere accesso a strumenti come Google Analytics o Google Webmaster Tools. Insomma a strumenti che vi permettano di avere dei dati quantitativi su come viene raggiunto il vostro sito, da dove, con che parole chiave, quanto tempo vi si fermano i visitatori e dove. Questo vi fornirà i dati necessari a capire se è il caso di cambiare qualcosa e come.

2) chiedete il parere ai vostri utenti, aggiungendo la presenza sul web tra i criteri che usate per misurare la qualità del vostro servizio. Non credo qualcuno vi dirà, come me, che il vostro sito fa schifo. Però potrebbero saltare fuori suggerimenti utili come: “è scritto troppo in piccolo”, “non riesco bene a trovare le cose”, ecc. ecc.

spingitori di spingitori di metamotori di ricerca

14 Mar

Ogni tanto sento parlare di metaOPAC. Ne ha parlato Francesco Piras a proposito di quello sardo, poi sul blog del Polo SBN Ligure, oppure perchè c’è un progetto su un Portale delle biblioteche in Veneto oppure un altro progetto simile in Friuli.

Sembra che ogni regione ne abbia oppure cerchi di costruirne uno. Ah, poi c’è il MAI. Ma andiamo con ordine.

Il concetto di meta-motore è legato soprattutto a quello di deep web, ovvero alla enorme mole di informazioni che non è  recuperabile dai comuni motori di ricerca. Fino a sei anni fa si stimava che l’insieme dei motori di ricerca avesse indicizzato circa il 20% dei contenuti disponibili sul web. Ora non so a quanto siamo arrivati, ma il concetto resta lo stesso, un motore di ricerca non indicizza tutto (e non sto parlando poi di cosa restituisce, solo di cosa indicizza).

Nel tempo sono nati quindi diversi strumenti (metamotori di ricerca o ricerche federate), per interrogare diverse fonti di informazione contemporaneamente e visualizzare i risultati in maniera omogenea. Il protocollo z39.50 c’era già prima del web, poi sono arrivati altri metodi (es. SRU/SRW). Tuttavia i metamotori spesso hanno alcuni limiti: la possibilità di usare solo un set limitato di parametri di ricerca;  si basano su dati strutturati in modo omogeneo; sono vincolati alla disponibilità della risorsa esterna.

Per questo motivo l’ultimo trend, quello dei cosiddetti next generation catalogs o discovery tools, è di spostare la raccolta dati prima della ricerca da parte dell’utente (il cosiddetto harvesting tramite il protocollo OAI-PMH). In sostanza viene catturato l’intero patrimonio di dati presente sulla fonte esterna, quindi viene indicizzato e reso disponibile dal motore di ricerca. La cosa è molto comoda per diversi motivi: si possono aggregare dati eterogenei e quindi “sistemarli” prima dell’indicizzazione; si possono applicare strategie di ricerca più efficienti; in generale è tutto più rapido 😉

A questo punto resta il problema di come sono strutturati i dati che vengono scambiati.

Il formato standard per lo scambio di dati bibliografici è l’ISO 2709, un insieme di codici numerici e valori debitamente separati. Nel tempo le specifiche di questo formato sono state implementate in diversi modi (es. MARC21, UNIMARC) e il metodo più diffuso attualmente consiste nella rappresentazione in linguaggio XML della struttura dei dati. Addirittura, grazie allo sviluppo del web semantico, si sta iniziando a parlare più genericamente di formati per la descrizione di risorse (RDF), per cui magari al posto dei codici numerici avremo costrutti semanticamente significativi.

Dovendo implementare un metamotore di ricerca ci si pone quindi le seguenti domande:

  • dove sono i dati
  • come sono fatti questi dati
Esistono però anche altre due domande a cui sarebbe bello rispondere quando si cerca di implementare un meta-motore di ricerca:
  • di chi sono i dati
  • a cosa servono

Rispondere alla prima domanda potrebbe aiutare notevolmente la diffusione e il riuso di dati, ovvero la consapevolezza del valore dei dati prodotti dall’istituzione.

La seconda invece ci ricorda dell’utente.

I discovery tool (così come prima i meta-motori) sono utilizzati più che altro in ambito accademico/scientifico, dove il servizio svolto dall’applicazione completa quasi sempre l’attività di discovery to delivery con un accesso immediato alla risorsa recuperata.

Cercando di applicare lo stesso meccanismo alle biblioteche di pubblica lettura, dove il “delivery” si risolve con il ritiro del materiale al bancone della biblioteca, mi chiedo se abbia senso investire in un meta-motore dal quale l’utente dovrà sempre e comunque essere rimbalzato ad un altro sito, magari il catalogo della biblioteca che possiede il titolo. A questo punto l’utente dovrà capire se il titolo è effettivamente disponibile o meno, se può prenotarlo o meno e in che modo ottenere l’eventuale interprestito. Questo moltiplicato per il numero di biblioteche/reti nel bacino sondato dal meta-motore.

Insomma, se volete realizzare un meta-motore per biblioteche di pubblica lettura, chiedetevi sempre per quale motivo lo state facendo, a cosa deve servire e chi dovrebbe usarlo. Se è per gli utenti, vagate nel web alla ricerca di esperienze simili e statistiche d’uso. Poi fatemi sapere cosa trovate.

Magari cercate anche di fare in modo che le biblioteche partecipanti al progetto abbiano una politica comune sull’interprestito e che l’applicazione realizzata alla fine sia chiara nello spiegarne i termini all’utente (non rimbalzatelo su un altro sito lavandovene le mani).

Personalmente, se volete realizzare un meta-motore….. non fatelo. Investite metà della somma a vostra disposizione per corsi tipo questo (qualcuno è andato? com’è stato? dalle slide mi sembra un corso entusiasmante!), il resto stanziatelo per mettere attorno al tavolo i responsabili dei cataloghi che vorreste ricercare, offrendogli le risorse per accordarsi sul servizio da offrire sul loro territorio.

Ah….un’ultima cosa importante….considerate il fatto che al giorno d’oggi nessun OPAC è più costretto a far parte del deep web. Grazie a progetti come la Open Library o Schema.org,ogni titolo del vostro catalogo può tranquillamente essere una pagina web indicizzata da normali motori di ricerca. Sapevatelo.

Don’t search our catalogues, search your browser!

13 Nov

Oggi è stata una giornata ricca di tweet interessanti 😛 Uno che mi è passato sott’occhio conteneva la frase: “Don’t search our catalogues, search your browser!“.

Mi è subito tornato in mente il Mycroft Project (e l’open search) e il fatto che probabilmente la nuova versione dell’OPAC SBN invalidava il plugin per Firefox. Così sono andato a correggerlo e ora funziona di nuovo 🙂
Lo trovate con questa ricerca e aprendo il link con Firefox vi chiederà automaticamente di aggiungerlo all’elenco dei motori di ricerca.

Probabilmente ne abuso un po’, tuttavia mi sembra una funzione estremamente comoda che permette di risparmiare inutili tempi di caricamento per dover comunque compilare un form di ricerca. Tra l’altro, se il sito lo prevede, durante la navigazione vi verrà proposto di aggiungerlo tra i motori. Attualmente ci sono 884 plugin per cataloghi di biblioteche (8 per l’Italia).

Allo stesso modo ho imparato come aggiungere un motore di ricerca a Chrome. E’ spiegato bene sulla guida di Chrome, ad ogni modo, per aggiungere rapidamente la possibilità di ricercare su SBN, basta cliccare la chiave inglese in alto a destra e quindi andare in Opzioni (o Preferenze). Dalla scheda Impostazioni di base vi basta cliccare sul pulsante Gestisci motori di ricerca… per aprire un riepilogo dei motori che potete usare. In fondo troverete la possibilità di aggiungere una nuova riga, simile alla seguente:

dove l’URL bordato di rosso dovrebbe contenere:

http://opac.sbn.it/opacsbn/opaclib?db=solr_iccu&select_db=
solr_iccu&from=1&searchForm=opac%2Ficcu%2Ffree.jsp&result
Forward=opac%2Ficcu%2Fbrief.jsp&do_cmd=search_show_cmd&struct
%3A1016=ricerca.parole_tutte%3A4%3D6&item%3A1016%3AAny=%s

Se come me avete impostato “sbn” come parola chiave per usare quel motore, vi basterà digitarla nella barra degli indirizzi, seguita da spazio (o tab), quindi dalla stringa di ricerca, per ottenere immediatamente i risultati.

P.S. mentre scrivevo l’articolo mi son detto “… e perchè non fare un plugin anche per il MAI – MetaOPAC Azalai?” Così ho fatto anche quello (per titolo, su tutti i cataloghi e tipi di documento), che però non può funzionare allo stesso modo per Chrome visto che il passaggio di parametri ad Azalai è un pelo più complesso. Ad ogni modo ricordo l’indicazione riportata sul sito del metaopac: “Questo metaOPAC è indicato per la ricerca di documenti poco comuni non trovati in altri cataloghi italiani. Usarlo come strumento di ricerca primario è sconsigliabile, perché produce risultati sovrabbondanti e rallenta il funzionamento.”

Errata conversione in UNIMARC del server z39.50 di SBN

26 Ott

Caspita!

Oggi a lavoro ho scoperto che il server z39.50 dell’Indice SBN è ancora collegato al “vecchio” OPAC SBN. Per essere precisi i record sono restituiti in formato UNIMARC solo a seguito di una rielaborazione non sempre corretta al 100%. Ad esempio le nature W sono restituite con indicatore 1 del campo 200 impostato a 1 invece che a 0.

Dall’ICCU comunque ci hanno confermato che a breve sarà di nuovo disponibile uno scarico UNIMARC corretto, così come riportato sul nuovo OPAC.

P.S. magari lo z39.50 si è sempre comportato così e io lo scopro solo ora. Intanto comunque lo scrivo qui, vedi mai che qualcun altro non lo sapeva.

%d blogger hanno fatto clic su Mi Piace per questo: