La Regione Emilia Romagna sta lavorando alacremente al miglioramento dell'accessibilità e dell'usabilità di Plone.

Dato che il futuro dell'editor WYSIWYG in Plone non è più Kupu (difficilmente personalizzabile e non troppo supportato) ma TinyMCE, già da tempo la scelta è stata di passare a TinyMCE anche nella versione 3 di Plone, usata in vari siti regionali.

Migliorare TinyMCE è più semplice che Kupu e lo dimostra come è stato possibile da parte nostra aumentarne le funzionalità per venire incontro ad alcune delle richieste della Legge Stanca (modifiche di cui si è discusso in un altro post, e ora integrate nella release ufficiale già dalla versione 1.1rc9); Altro particolare: trovo importante che questo editor esista anche come progetto indipendente.

Altre novità: la gestione dei link

Una richiesta recente per aumentare l'usabilità dei documenti è stata la seguente:

Modificare Plone in modo che i link interni, se fatti a contenuto di tipo File, mostrino l'icona del tipo di contenuto e la dimensione del file stesso

Una simile modifica aumenta l'usabilità generale della pagina, nonché impatta col Requisito 19 della Legge Stanca.
Dopo una prima analisi è risultato chiaro come fosse necessario scrivere un nuovo plugin per TinyMCE.

Come funziona collective.tinymceplugins.advfilelinks?

Il prodotto rilasciato fornisce il minimo delle modifiche possibili a TinyMCE (ma non minime quanto avrei voluto... ne parliamo dopo). Si tratta di un un plugin aggiuntivo (e per fortuna la presenza di plugin è prevista non solo dall'editor ma anche dalla sua configurazione di Plone) che sostituisce quello predefinito di Plone per i link interni (dal nome autoesplicativo plonelink).

Dopo un'analisi attenta di come poter ottenere le funzionalità richieste e della flessibilità delle API di TinyMCE, su indicazione della Regione stessa abbiamo preso la seguente strada, forse un po' limitata ma di minimo impatto sullo sviluppo e con una resa eccezionale se il browser è aggiornato:

• I link a file acquisiscono un nuovo attributo type (previsto dallo standard HTML anche se poco conosciuto) ed viene fornito un CSS aggiuntivo contenente varie regole per fornire l'icona.
  Esempio:
  

  a[type='application/pdf'] {
      background: url(pdf.png) no-repeat 0 50%;
      padding-left: 20px;
  }

  Questo tipo di regola CSS ha un buon supporto (da Internet Explorer 7 in poi).
• La dimensione del file è prima di tutto inserita nel title del link (che normalmente il plugin originale non fornisce) ma un buon effetto è ottenuto associando una ulteriore regola CSS:
  

  a.internal-link-tofile:after {
  	content: " ("attr(title)")";
  }

  Questa magica regola CSS (fa parte dello standard CSS 2, per quanto Internet Explorer la supporti solo dalla versione 8 in poi) inserisce del testo aggiuntivo dopo i link con classe internal-link-tofile.
  Il contenuto di questo testo è preso dall'attributo title, ma vi vengono aggiunte delle parentesi. Ovviamente questa classe CSS aggiuntiva è inserita dal nostro plugin in aggiunta alla già nota internal-link.

L'ultima funzionalità è forse la più interessante e per quanto il metodo usato sia davvero poco invasivo e l'effetto finale a dir poco bello, il limite ad avere Internet Explorer 8 è ancora grande.
E' comunque sopportabile? Sì, dato che l'attributo title rimane comunque disponibile agli utenti (e agli Screen Reader) in tutti i casi.

Note tecniche di estendibilità

TinyMCE per Plone sfrutta chiamate AJAX per richiedere al server informazioni sui contenuti. Come sempre le modifiche lato server sono minime e perfettamente integrate con quanto Plone già fornisce.

E' bastato fornire un nuovo adapter.

  <adapter
        for="Products.ATContentTypes.interface.IATFile"
        provides="Products.TinyMCE.adapters.interfaces.JSONDetails.IJSONDetails"
        factory=".adapters.JSONDetails"
        />

Grazie alla ZCA, questo adapter aggiuntivo interviene solo per i contenuti di tipo File o sottotipi (a volte ho l'impressione che senza adapter i plonisti non vivrebbero più!).

I problemi maggiori sono lato client... L'idea sarebbe come sempre estendere e non sovrascrivere. In un mondo perfetto questo plugin si sarebbe dovuto integrare con quello preesistente, sfruttandone tutto il codice presente.

Non mi è ancora chiaro se questo non è stato possibile per limiti miei, del plugin stesso, o di TinyMCE, ma il risultato per quanto funzionante è anche una copia di molti dei file originali (una forma di branch del plugin)... probabilmente non dormirò di notte per aver dovuto copiare i file di lingua... ma dopo tutto è una versione alpha!

Il limite maggiore di TinyMCE attualmente è che non usa jQuery (per quanto ci sia un progetto che integra jQuery e TinyMCE) e soprattutto che non c'è uso di eventi Javascript.

Sarebbe stato bello (ma che dico bello! Utile) se al click del mouse sul pulsante radio che seleziona un file piuttosto che un qualunque altro documento a cui associare il link, venisse lanciato un evento Javascript... evento al quale un buon plugin per jQuery avrebbe potuto reagire per eseguire azioni...

Per ora questo non pare possibile, ma sarebbe un buon passo avanti per TinyMCE.

Nota sul namespace

Sono rimasto colpito nel vedere come sulla collective ci siano così pochi plugin the TinyMCE (l'unica eccezione pare essere collective.tinymcetiles). Ci sono state sanguinose discussioni in passato sull'uso di namespace a 2 o 3 livelli (ne ricordo una completa e interessante). In questo caso l'uso dei 3 livelli mi è parso opportuno.

Spero che in futuro altri contribuiscano al gruppo di plugin collective.tinymceplugins e figli!

Riferimenti

• Plugin su plone.org
• Plugin su Python Cheeseshop

C'è ancora chi crede che un sito Plone si riconosca a prima vista: può essere, se parliamo di installazioni "out of the box" o comunque se si decide di restare nelle skin più classiche. Ma certamente non è un principio generale: la flessibilità di Plone è testimoniata non tanto dalla possibilità di impostazioni grafiche complesse e innovative, quanto dalla sua possibilità di mimetizzarsi completamente in un layout grafico preesistente.

Due casi di studio, entrambi provenienti dall'ambito della Regione Emilia Romagna, dimostrano questa flessibilità con particolare evidenza:

• Nel sito "Io Partecipo" / "Uno x uno", che propone una soluzione mista Plone / non Plone, l'integrazione trasparente di Plone è stata ottenuta grazie a Deliverance (diversi dei nostri tecnici hanno parlato di questa soluzione nelle loro presentazioni: Massimo, Stefano, e nel nostro blog). Deliverance consente di ridistribuire gli elementi grafici di uno o più layout esistenti, assemblandoli in modo differente e - se necessario - armonizzandoli dal punto di vista grafico. Nel caso di "Io partecipo", tutti gli elementi del layout grafico sono riproposti direttamente da un preesistente sito, salvo la colonna di sinistra (notizie, commenti, argomenti) che è invece tratta da un sito plone ad hoc. Ciò ha consentito di mantenere inalterata l'originaria infrastruttura, pur offrendo ai redattori i vantaggi di Plone per la redazione delle informazioni modificate più di frequente.
• Invece, nel caso di Ermes, il portale della Regione Emilia Romagna, gli utenti non si sono accorti di nulla nonostante l'intero portale sia stato interamente reingegnerizzato in Plone. In questo caso, Plone è stato meticolosamente personalizzato in modo molto granulare, per caratterizzare ogni elemento visibile secondo i tematismi grafici e la struttura del portale originale: la buona riuscita dell'operazione può essere testimoniata da chiunque abbia usato Ermes negli ultimi mesi - a parte la differente struttura degli URL, nulla denuncia il cambiamento di tecnologia. Altrettanto rimarchevole il fatto che, sebbene l'originale implementazione fosse in HTML statico e quindi particolarmente leggera, i tempi di caricamento delle pagine in Plone sono immutati: insomma, l'enorme vantaggio di una gestione dei contenuti immediata e "through the web" non si paga in termini di prestazioni. Tra l'altro, a differenza della precedente implementazione statica, il portale Plone sarà agevolmente adattabile ad altri media palmari (ipad/iphone/smartphone in genere).
  

In conclusione, le ragioni per non rinunciare alla veste grafica "storica" di un portale sono molteplici, soprattutto legati all'elevato numero di utenti abituali, e bisogna trasformare questa esigenza in un'opportunità. Il fatto che Plone lo consenta è importante per molti validi motivi:

• dimostra la flessibilità della tecnologia
• abbatte un ostacolo spesso insormontabile: la paura del cambiamento; L'alibi "Ma i nostri utenti sono abituati a vedere le cose in questo modo!" si dissolve con un "E così continueranno a vederle!";
• preserva gli investimenti passati: se il progetto di comunicazione su cui è disegnato il portale è valido, può avere senso mantenerlo anche al variare della tecnologia.

Prima di tutto: usi ZopeSkel... vero?

La frase "non uso ZopeSkel perché sono abituato a fare le cose a mano" non è una scusa valida!

Personalmente uso ZopeSkel solo per la creazione iniziale dell'egg, poi non mi addentro mai molto nell'uso dei "paster subcommands" (ma non sempre... creare nuovi contenuti per Archetype è comodissimo), ma quello è sufficiente. Usare ZopeSkel per generare lo scheletro dei propri egg significa seguire la convenzione e lo standard!

Non mi addentro ulteriormente sull'argomento... se non usi ZopeSkel e sei incuriosito puoi leggere l'ottimo articolo che trovi su plone.it.

Le novità nascoste

Prima di tutto verifica di avere disponibile l'ultima versione (al tempo in cui scrivo siamo alla 2.17):

keul@redturtle:~$ sudo easy_install -U ZopeSkel

Notate innanzi tutto che il vostro sistema ha ora disponibile un secondo comando oltre al già conosciuto paster (hai letto l'articolo sopra, vero?). Il nuovo script è zopeskel.

Cosa fa? A cosa serve? E' principalmente una forma semplificata del primo script... diciamo un "paster for dummies", ma la vera comodità e fulcro di questo articolo è la possibilità di creare tramite lo script zopeskel un file di configurazione con alcune preferenze di default.
Possiamo finalmente usare paster e premere molte più volte "invio" (accettando la risposta predefinita) di quanto non venisse fatto fin'ora.

Lanciando la guida di zopeskel otteniamo questo:

keul@redturtle:~$ zopeskel --help
...
You can generate a starter .zopeskel file by running this script with
the --make-config-file option. This output can be redirected into
your ``.zopeskel`` file::

    bin/zopeskel --make-config-file > /path/to/home/.zopeskel
...

In pratica, nella nostra home possiamo ospitare un file con nome ".zopeskel" con alcune configurazioni predefinite e zopeskel stesso ci permette di generarne uno di esempio, con una sintassi valida, da personalizzare poi.

keul@redturtle:~$ zopeskel --make-config-file > ~/.zopeskel

Le opzioni non sono poche e forse un tantino esagerate. Potreste ad esempio avere configurazioni diverse a seconda del tipo di comando paster che state usando...
Io rimango per un uso semplice!

# This file can contain preferences for zopeskel.
# To do so, uncomment the lines that look like:
#    variable_name = Default Value

[DEFAULT]

expert_mode = all
version = 0.1.0
author = RedTurtle Technology
author_email = sviluppoplone@redturtle.net

[archetype]

# Expert Mode? (What question mode would you like? (easy/expert/all)?)
# expert_mode = easy
...

La sezione [DEFAULT] sarebbe solitamente vuota ma avete esempi completi in tutte le altre sezioni (una per ogni tipo di template paster disponibile) anche se tutte commentate.

Se come me volete configurare solo la sezione [DEFAULT], usate qualche copia incolla!

Quella postata qui sopra è esattamente la mia configurazione, che vado ad analizzare.

• expert_mode. E' un'opzione piuttosto nuova e il default sarebbe "easy"; è interessante perché permette di porre all'utente "meno domande"... ma visto che fingo di essere uno smanettone, preferisco che mi venga chiesto "tutto".
  Scherzi a parte, alcune delle domande che vengono saltate le trovavo invece importanti.
• version. La versione del prodotto. Il default è 1.0, ma personalmente preferisco 0.1.0, ben considerando che paster viene usato alla creazione... è molto probabile che la prima release del vostro super prodotto non sia tanto super... e che sia di qualità alpha o beta.
• author. Nel mio sistema, a lavoro, è normale che il codice sviluppato sia della mia Azienda. Niente più scrittura a mano del nome dell'Azienda e niente più differenze tra me e il mio collega.
• email. Di nuovo convenzione (un unico indirizzo aziendale per lo sviluppo plone)... ma potrei specificare la mia email personale!

Teniamo comunque presente che questi valori sono solo i default. La gestione dell'eccezione è sempre possibile (non diventate troppo pigri ... potete sempre cancellare la risposta che paster sta proponendo e scrivere da capo... come poi avrete fatto fin'ora!).

Un file .zopeskel in ogni azienda

Perché no? Pensare che ogni sistema per sviluppatori all'interno di un'azienda abbia questa configurazione porta uniformità al rilascio di codice alla comunità. Non sto ovviamente parlando delle prime opzioni che abbiamo illustrato, che sono più che altro preferenze davvero personali.

Potrebbe non essere il vostro caso, magari la Vostra Azienda preferisce mantenere come autore lo sviluppatore stesso (oppure mettere sempre come autore il nome del capo programmatore che vive sulle vostre spalle e che vi ruba la fama). Altre magari vorranno che tutto il codice risulti fatto dall'Azienda, ma potrebbe voler mantenere la Vostra e-mail (così che siate voi ad essere disturbati in caso di problemi).

Questo, come dicevo è come il mio sistema è configurato qui in RedTurtle... a casa mia ho un PC che ogni tanto uso per i miei personali progetti Plone. Ovviamente anche là uso paster ma in una configurazione diversa!

Provate anche voi. E' comodo...

l'evento

Dal 26 al 27 maggio 2010 si  tenuto, nella bellissima cornice sorrentina, l'European Plone Symposium 2010. L'evento, organizzato da Abstract,  è ormai un appuntamento fisso per la comunità Plone.

Organizzato in contemporanea con il Plone Symposium East 2010 (Pennsylvania, US), l'evento si è aperto con l'intervento di Geir Bækholt di Jarn per fare il punto sulle novità dell'ormai imminente Plone 4. Siamo ormai alla beta 3 e l'enfasi è stata posta sui tanti miglioramenti anche dal punto di vista dell'interfaccia e delle prestazioni.

Lo sforzo degli sviluppatori, anche dei Tune-Up, compreso il 31-esimo TuneUp che si è svolto durante lo sprint di venerdì 28 maggio, è volto a chiudere gli ultimi ticket per poter rilasciare la prima versione stabile di Plone 4.

Plone 4

La versione 4 può essere considerata una versione di transizione, sia per gli sviluppatori che per gli utenti "finali", a Plone 5, dove, si vedrà all'opera Deco, l'innovativo sistema di composizione "a tasselli" dei contenuti.
Inoltre Geir ha parlato già di alcune delle novità che ci aspettano in Plone 4.1:

• plone.app.discussion per una più evoluta gestione dei commenti
• plone.app.registry
• plone.app.contentlisting
  
• evoluzione delle collezioni
• collective.amberjack uno strumento supportato da RedTurtle per la crezione di tour guidati.

I Talk

Matt Hamilton

Nel primo intervento, rivolgendosi soprattutto agli integratori, ha discusso di un approccio interessante e forse non così praticato come si potrebbe pensare. L'idea è che quando ci si trova di fronte alla necessità di dover integrare un prodotto con nuove funzionalità si cerca sempre di non alterare il prodotto originale per mantenere la possibilità di aggiornarlo.

Per raggiungere questo obiettivo in alcune situazioni, se il codice del prodotto originale lo consente, è possibile sftuttare gli eventi. L'idea è semplice: basta registrare il codice da eseguire quando si scantena l'evento e il gioco è fatto. Matt ha portato un esempio di plone.app.discussion a cui ha dovuto aggiungere una funzionalità antispam e la modifica fatta a GetPaid (il modulo usato per la gestione di sistemi di e-commerce) per la gestione delle registrazioni al sito della Plone Conference 2010.

L'altro intervento di Matt è stato dedicato alla conferenza organizzata dallo stesso Matt e da Netsight a Bristol (UK).
Matt ha sottolineato che, a parte il fatto che probabilmente non ci sarà lo stesso cibo "faboulus" dell'Hotel Mediterraneo, l'attenzione dell'organizzazione sarà concentrata su molti aspetti, dalla rete affidabile e veloce, agli alloggi per i partecipanti. Inoltre il terzo giorno della conferenza sarà impostato in modalità barcamp come già fatto per Budapest. 

Rok Garbas ha presentato 2 argomenti interessanti.

Durante l'intervento dedicato a Transmogrifier ho potuto trovare conferma dei grandi passi in avanti fatti da questo sistema nell'ultimo anno.

L'idea di base è semplice ma molto efficace e realizzata con un codice veramente ben fatto: l'idea è di avere un meccanismo per importare contenuti in Plone. Si tratta di configurare le varie fasi (pipeline) dove, in ognuna, viene fatta una operazione sui dati. Esistono varie moduli che sono già stati realizzati e pacchettizzati per poter gestire alcuni casi tipici (dalla gestione dei CSV, al crawler dei siti da cui è possibile parsare l'html).

Nell'altro intervento Rok ha presentato Deliverance. In questo intervento introduttivo si è potuto toccare con mano l'idea che sta alla base del sistema: fare in modo che i designer Web, che hanno esperienza con l'uso di HTML e CSS, possano fare temi per Plone senza dover per forza imparare tutti i segreti del theming di Plone; argomento che sulle prime prime può mettere un po' in crisi gli aspiranti designer Plone. Rok ha anche passato in rassegna le differenze tra la sintassi di Deliverance e XDV. L'idea di Rok, e portata avanti anche durante lo Sprint dei giorni successivi è quella di trovare una sintassi comune per le funzioni più usate dai 2 sistemi. 

...e ancora..

Interessanti anche gli altri interventi dedicati ai casi di studio:

• Simone Deponti ha presentato il caso di studio per la gestione di un importante sistema di E-Commerce
• Roel Bruggink & Rob Gietema hanno presentato il caso di studio Humanitas.

Entrambi hanno dimostrato quanto si possa fare con Plone.

Un'ultima considerazione finale.

Ormai seguo gli eventi Plone "ufficiali" da 5 anni (il primo "vero" evento Plone a cui ho partecipato è stata la Plone conference di Vienna del 2005) e durante questo Simposio ho trovato conferma di quanto ho osservato già a Budapest l'anno scorso: l'intera comunità si è evoluta ed è maturata nel corso di questi anni. Questo si può "dedurre" da vari segnali: dal piano a lungo termine di Plone, dallo spessore dei vari talk, ai casi di successo sempre più importanti e significativi, alla intergrazione con altri framework Python based (e non solo) e, perchè no, anche alla crescita professionale della comunità italiana.

Arrivederci a Bristol!

Gli obiettivi

Abbiamo una milestone da raggiungere: quella del rilascio della versione 1.1a. Questa comprendeva:

• la risoluzione di alcuni bug o problemi di interfaccia
• il refactoring del codice javascript
• il brainstorming su come evolvere il sistema

Abbiamo risolto i bug, introdotti ulteriori miglioramenti all'interfaccia e rifattorizzata buona parte del codice javacript. Rimane qualcosa da finire, nel complesso è stato un successo. 

Inoltre, sono stati introdotti cambiamenti strutturali alla definizione del tour.

Luca, Federica, Mirco ed Andrew hanno fatto un gran lavoro.

Il punto focale però è stato il confronto con la comunità. Avevamo preso alcune decisioni che ci è sembrato opportuno sottoporre al vaglio dei presenti e abbiamo ottenuto ottimi suggerimenti e conferme sulla strada intrapresa.

Windmill

Windmill diventerà l'interfaccia principale di creazione di un tour. E' il modo più semplice per crearlo, aggiornarlo, tradurlo. E' di enorme efficacia sia per un end-user in quanto servirà poco addestramento che per uno sviluppatore che potrà creare al tempo stesso un tutorial per i suoi add-on e un test funzionale che verifichi che l'introduzione di modifiche non inficino il comportamento generale del sistema.

Questa conferma ha portato ad alcune riflessioni e variazioni di indirizzo.

formato dei tour

Il formato cambia. Non più complessi dizionari scritti in python, ma file di configurazione altamente leggibili. qualcosa del tipo:

[amberjack]
steps = 
        0_create-a-new-folder
        1_fill-out-the-fields
        2_publish-the-folder
        3_all-done
title = Add and publish a Folder


[0_create-a-new-folder]
blueprint = collective.amberjack.blueprints.step
title = Create a new folder
url = /
text = Folders are one of ....
validators = 
        python: isManager
        python: isNotFolderCreated
microsteps = 
        0_0_microstep
        0_1_microstep
        0_2_microstep


[0_0_microstep]
blueprint = collective.amberjack.blueprints.microstep
description = If you don't want to perform the ...
automatically done by your browser.


[0_1_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = menu_add-new
description = Click the [Add new...] drop-down menu.


[0_2_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = new_folder
description = Select [Folder] from the menu.

Sarà ovviamente possibile salvare i tour, in questo nuovo formato, direttamente dall'interfaccia di Windmill.

Ovviamente è necessario avere un sistema di conversione dei vecchi tour: è stata creata l'utility "tour_converter" (in collective.amberjack.core) che migra vecchi dict-based tour in nuovi cfg-based tour.

I tour saranno quindi semplici file. Questo significa che la sorgente da cui verranno "pescati" non sarà più un package scaricabile da pypi, ma potrà essere salvato in locale, messo su un server condiviso, scaricato da sorgenti eterogenee (svn, http server, ftp, ecc.). Ovviamente abbiamo una registrazione "classica" via zcml oppure una più "cool" via pannello di controllo di plone.

E' già pronta e funzionante una versione experimental che funziona con questo nuovo approccio e i 12 plonetour sono stati già convertiti e pronti per l'uso.

Un discorso a parte per le traduzioni: dobbiamo reimplementare il meccanismo in quanto ora non abbiamo più file .py. Contiamo di definire una modalità di traduzione simile alla precedente, ma in qualche modo occorrerà effettuare qualche variazione al sistema di generazione dei file .po.

sandbox

Il brainstorming pre-serale in giardino è stato molto utile anche in questo caso. 

L'idea che ne è scaturita è quella di fornire un folder personale dedicato ai tour all'interno del quale l'utente abbia tutti i diritti necessari per poterli eseguire completamente. Questo copre il 90% delle situazione secondo le previsioni della maggior parte dei presenti.

Con questa sandbox 1.0 si potrà già creare un "demo.plone.org": chiunque potrà provare Plone senza doverlo scaricare.

Inoltre è semplice per ogni sviluppatore di add-on montare un'istanza in cui includere il proprio tour ed eventualmente richiedere alla foundation il dominio: "demo.myaddon.plone.org"

Assolutamente semplice sarà fornire un sistema che ogni notte ripristini il portale ad una situazione "pulita".

Non sembra interessare, almeno in questa fase, un sistema che automaticamente crei un'istanza on-the-fly che permetta all'utente di provare plone in completa autonomia. quel 10% di target-user possono tranquillamente utilizzare un comodo UnifiedInstaller

abbiamo un team di supporto!

Dalla 1.0x RedTurtle ha deciso di supportare il progetto. 

Questo non significa che collective.amberjack sta diventando un progetto aziendale, ma semplicemente che avremo un team che ne porterà avanti lo sviluppo.

Il team, oltre a me, è composto da Mirco Angelini, Federica D'Elia, Andrew Mleczko e Luca Fabbri. All'ultimo sprint a Ferrara abbiamo avuto il supporto di Jacopo Deyla e il ritorno di Giacomo Spettoli (tra i primi contributori) entrambi della Regione Emilia Romagna.

Ora, sei ancora di più il benvenuto se vorrai partecipare allo sviluppo, supportare l'iniziativa o semplicemente utilizzare il sistema. Il tuo contributo sarà ancora più utile ora che qualcuno lo porterà avanti sistematicamente.

what's new? 

Questa prima release 1.0x supporta completamente Plone 4:

• i 12 tour sono stati completamente rivisti
• è stato introdotto il supporto per TinyMCE
• abbiamo un piano di battaglia

what next?

Dicevo di un piano di battaglia. Il piano prevede che al prossimo sprint a Sorrento si concludano le operazioni che ci porteranno ad una versione 1.1 rifattorizzate e ulteriormente migliorata. 

Nel frattempo predisporremo una serie di step che ci porteranno ad avere un sistema più solido, usabile e soprattutto estensibile.

Contiamo di introdurre Windmill come tool di creazione di tour via web. I primi tentativi sono molto promettenti. Andrea Benetti sta portando avanti la parte di studio che verrà integrata successivamente in collective.amberjack.

Dove puoi seguire il progetto?

Se sei interessato a partecipare, i posti dove ci incontriamo sono questi:

• launchpad, per la gestione del progetto (blueprint, bug, ecc.)
• coactivate, ci è utile per documentare il tutto attraverso il suo wiki e per gestire la mailing list
• il codice è tutto rilasciato su collective.

Se, viceversa, vuoi utilizzare il sistema, pypi è il tuo amico:

Chi trova un amico....

Mesi fa, in un incontro strategico con esperti di marketing, abbiamo appreso con sorpresa che il "passaparola" tra Clienti soddisfatti e potenziali nuovi Clienti, che per noi è la norma, rappresenta il livello massimo del successo di mercato.

Col senno di poi, ci siamo resi conto di aver sempre saputo che un Cliente soddisfatto è anche un amico prezioso: PloneGov Italia è in fondo l'estensione a un livello più alto di questo principio di scambio di informazioni utili. Sentire qualcuno che dice "Ti consiglio Plone" per noi è quasi altrettanto importante che sentir dire "Ti consiglio RedTurtle" (per inciso, ad oggi metà degli Enti PloneGov Italia sono nostri Clienti).

La "Plonopoli" emiliana

Scendendo nel pratico: aver trovato la Città giusta (la nostra: a Ferrara Università, Camera di Commercio, Comune, Provincia, AUSL e AOU Sant'Anna tutti usano Plone), il Cliente giusto (AUSL Ferrara) e la persona giusta (Isabella Masina dell'Ufficio Comunicazione), ci ha consentito di mettere rapidamente in piedi un evento oggettivamente utile non solo per noi, ma soprattutto per gli stessi Enti che vi hanno preso parte.

L'occasione giusta

Consolidati luogo, Cliente e interlocutore, il World Plone Day ha fornito l'elemento mancante: l'occasione giusta. Isabella, ben coordinandosi con i responsabili di riferimento, capaci di cogliere il senso dell'iniziativa, e appoggiandosi a RedTurtle per individuare i relatori più interessanti, ha messo in gioco la capacità organizzativa del suo Ente, e (con una tempestiva adesione) la "fratellanza" PloneGov Italia, riuscendo a coinvolgere, oltre ai membri Ferraresi di PloneGov Italia, anche la Regione, AUSL Bologna ed anche Enti fuori regione come Ospedali Galliera Genova.

E' ovvio che questi stessi enti, compresi quelli già Clienti RedTurtle, non sono a disposizione di un'azienda e mai si sarebbero mossi per un evento "marcato" RedTurtle. Invece, le dinamiche di PloneGov e il modo con cui la AUSL si è messa in gioco, simile a quello già sperimentato da Camera di Commercio di Ferrara, hanno consentito a Enti differenti, uniti dall'appartenenza a PloneGov Italia, di investire il loro tempo in un'azione di autopromozione della tecnologia, lasciando spazio a nostri interventi tecnici a fronte di una piccola sponsorizzazione.

"A collective win-win"

Così abbiamo visto AUSL differenti parlare tra loro e con Comuni e Aziende Ospedaliere. Perchè la cosa ci faccia piacere, è chiaro, ed è legittima la speranza di aumentare il numero di nostri Clienti soddisfatti. La cosa interessante è che tutti assieme abbiamo abilitato un modello trasparente, lecito e non invadente per aiutare i nostri Clienti a condividere la loro soddisfazione, parlandosi tra loro di problemi e di soluzioni Plone. Forse siamo davvero al top del marketing....

Mentre tentavo di riassumere i rilasci pubblici di prodotti Plone sviluppati da RedTurtle, compilando la tabella ora disponibile sul nostro sito, mi sono reso conto di due cose:

• prima di impegnarmi nella raccolta di informazioni sui nostri prodotti, non ero consapevole di quanto siamo stati capaci di fare: certamente, il resto del mondo ne sapeva ancora meno, così posso senz'altro affermare che la nostra lista di prodotti Plone va a sanare un punto dolente della nostra visibilità
• il numero e la qualità dei nostri contributi è eccezionale, come testimoniato dal numero di download: Amberjack e Carneade, che hanno ottenuto visibilità internazionale all'ultima Plone Conference, sono la punta dell'iceberg, e soluzioni come l'integrazione dei Google Docs, RedTurtle Video, e l'integrazione con Google Maps sono egualmente meritevoli di menzione, per non parlare delle cose più tecniche come l'integrazione con ExtJS o i moduli, a quanto pare molto graditi, che supportano FSS.

In futuro, tornerò sull'argomento. Ora, prima di chiudere, mi piacerebbe farvi vedere qualche numero sui più scaricati tra i nostri prodotti:

redturtle.portletpage.views                  :    338  
collective.googlesystemstorage               :     40  
redturtle.smartlink                          :   1373  
redturtle.extjs                              :    323
collective.googlemodifycontent               :     37  
redturtle.speedupui.pathbar                  :    242
redturtle.custommenu.factories               :    100
redturtle.catalogmount                       :    330
collective.googlesharing                     :     36  
redturtle.maps.portlet                       :    392
redturtle.externalizelink                    :    214  
redturtle.imagedevent                        :    888  
redturtle.bent                               :    373
collective.flowplayer_toolbar                :    158
Products.Plone2FSS                           :    861  
redturtle.hide_subtypes                      :     76  
munin.plone                                  :     34
collective.googleauthentication              :     38  
redturtle.maps.core                          :   1479  
collective.relatedof                         :     14
Products.PloneboardPasteObject               :     38  
Products.AutoRoleFromHostHeader              :     50  
collective.navigationtoggle                  :     94  
redturtle.portlet.lightreviewlist            :    351  
munin.zope                                   :    142
redturtle.fss                                :    567  
redturtle.video                              :    817  
collective.discussionintegration.plonegazette:     77