Migrazione da PostNuke a Plone: la banca dati CROP (S. Carluccio, CNR-ISMAR)
La scelta di Plone per la comunicazione istituzionale dell'INAF
1. La scelta di Plone per la comunicazione
istituzionale dell’INAF
Serena Pastore - INAF
Caterina Boccato - INAF
Bologna 20 Maggio 2010
Plone for Research and University Day
3. Obiettivi iniziali
•Ottimizzare il flusso di lavoro
•Ottimizzare il flusso dell’informazione
•Automazione dei processi di
pubblicazione
•Semplificazione
www.inaf.it
Enterprise Web CMS + Open source tecnology = Plone
3
4. Perchè abbiamo scelto Plone? E’ “safe and flexible”
- Architettura software stratificata (es. web server
esterno + application server) integrazione con altri
prodotti sviluppati per Zope,
-Vasta comunità di utenti internazionali (Plone
conference annuali, World Plone Day, fondazione
Plone che supporta la comunità dal 2004) sviluppo
e supporto continuo al software (prima release nel
2001),
Dal punto di vista della pubblicazione web:
-Definizione di workflow diversi,
-Gestione portlet,
-Autenticazione (definizione puntuale degli utenti
stile “unix”), affidabilità, scalabilità, integrazione, …,
-Audio/video,
-Flessibilità nel progetto grafico (*)
4
5. Vantaggi
Facile da usare (lato utente)
Sicurezza: chiara definizione di diversi tipi di utenti con ruoli e
permessi (ruoli, workflow e regole sui contenuti)
Es. sito in produzione
Affidabilità e robustezza software dal 2006 rimasto
senza “sistemista” –
e quindi senza
Sistema di gestione documenti (DMS) manutenzione - per
almeno 6 mesi -
senza evidenziare
Community affidabile e pronta nel rispondere ai problemi problemi
proposti
Architettura software: CMS come applicazione di un
application server e quindi facilmente integrabile con qualsiasi
altra sviluppata per Zope
Continuo sviluppo del software in un’unica direzione (cfr.
mambo diviso da joomla)
5
6. Svantaggi
Alta curva di apprendimento del software (almeno iniziale e per gli sviluppatori)
Alcuni prodotti non vengono sviluppati per le versioni successive del software
Dipende da Zope
Non usa DB relazionale (?)
Problemi evidenziati nella nostra configurazione (dovuti però alla nostra
implementazione e alla nostra non-conoscenza di tutte le potenzialità del
software)
Problemi di performance nel caricamento delle pagine
Grafica “povera”
6
8. 2010: Cosa si vuole ottenere: requisiti generali
Sito bilingue
Sito sviluppato in modo aderente alle leggi vigenti e alle direttive in termini di
accessibilità e di usabilità dei siti web (tenendo anche conto delle Linee Guida
per i siti web della PA in fase di consultazione pubblica)
Sito disponibile per qualsiasi tipo di dispositivo compresi quelli mobili
(crossbrowser)
Possibilità di definire un template che specifici layout e grafica generale del
sito da esportare per i siti web delle sedi specfiiche sviluppate con altre
tecnologie HTML o altri CMS open-source (es. Joomla)
Fruibile e accessibile da chiunque
Importazione dei contenuti del vecchio sito
Nuova grafica più accattivante
Più performante nel caricamento delle pagine
8
9. 2010: Restlying del sito – Requisiti tecnologie web 2.0
Attivazione feed RSS e tag
Presenza di riferimenti a social network (es. facebook, twitter, etc)
Possibile integrazione con tecnologie Google (es. Google maps o
Google docs)
Presenza di un possibili forme di comunicazione pubblica (es. blog,
newsletters)
Altro ….
9
10. 2010: Requisiti hardware e software
Piattaforma hardware costituita da server ridondato e con alte
caratteristiche di performance e affidabilità
Piattaforma software essenzialmente su sistema operativo di tipo
Linux/Unix, middleware basato su software open-source o sito distribuito su
almeno due sedi, per garantire una ridondanza geografica, con load balancing
a livello software (non realizzato quindi al solo livello DNS)
Possibilità di accesso dall’esterno sicura (accesso autenticato via https) per
gli utenti registrati
Eventuale compatibilità con software di single-sign-on (SSO) quale
framework Shibboleth per integrazione con servizi della rete GARR.
10
11. 2010: Restlying del sito – con riferimento alla sede centrale
Fornire uno strumento semplice per l’inserimento dei contenuti
Garantire un archivio delle documentazioni inserite e una scadenza definita
per alcuni documenti (es. bandi)
Garantire un flusso documentale legato a specifiche azioni (es. tutti i
documenti collegati alle varie fasi di un concorso) e quindi necessità di un
Document Management System (DMS)
…
Il tutto anche nell’ottica di una già intrapresa
collaborazione con altri enti (es. INGV) che utilizzano lo
stesso software per individuare strategie comuni dati gli
obiettivi simili in ambito di comunicazione e volendo
condividere conoscenze, esperienze e possibilmente
software
11
12. La scelta?
•Garantisce, tramite vari prodotti disponibili,, il soddisfacimento di tutti i requisiti richiesti
•Ormai è un prodotto stabile: ogni nuova versione presenta notevoli miglioramenti
rispetto alla precedente
•Plone è parte di un ecosistema: è stato pensato e sviluppato nello specifico come
soluzione CMS per creare e mantenere siti web pubblici e intranet usando il browser. Si
possono aggiungere vari funzionalità (es. webBlog, newsletter, chat, RSS ) o integrarlo con
vari strumenti “web 2.0” (flickr, google maps, etc.) tramite specifici prodotti add-ons.
•Con implementazioni specifiche sarà possibile risolvere molti problemi evidenziati dai
nostri utenti (es. Grafica poco accattivante, problemi di performance, ..)
•Diffusione in enti della PA e quindi software in grado di rispettare le leggi vigenti in
materia di siti web (es. Legge Stanca per accessibilità)
•Presenza di vari fornitori che offrono servizi di supporto di vario tipo per l’interno
framework
12
14. Plone per l’Enterprise 2.0
Adottare approcci organizzativi e tecnologici per nuovi
modelli organizzativi basati sul coinvolgimento,
collaboiorazione e la condivisione della conoscenza
(applicazione di strumenti di social computing)
Domande?
INAF
serena.pastore@oapd.inaf.it
caterina.boccato@oapd.inaf.it