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

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:

we have a support team!

Starting from 1.0 release, RedTurtle decided to support the project providing a 4 person team.

It doesn't mean that collective.amberjack is going to be company branded - quite the contrary - it means that we have a stable team that is going to enhance and mantain the tool.

Except me, the team contains: Mirco Angelini, Federica D'Elia, Luca Fabbri e Andrew Mleczko. During the last Ferrara' sprint, we were glad to have Jacopo Deyla's contribution and the Giacomo Spettoli's return (former contributor) both of them from Regione Emilia Romagna.

You are even more then welcome to participate in the development, in supporting the initiative or just in using and testing the tool. Your contribution will be more useful since, from now, there will be someone that will take care of it.

WHAT'S NEW? 

This 1.0 release supports Plone 4:

• the 12 tours has been completely revised
• the TinyMCE support has been added
• we have a battle plan

WHAT NEXT?

I talked about a roadmap. It assumes that during next Sorrento sprint we'll complete the tasks that will refactore the code and improved 1.1 release.

In the meanwhile we're going to schedule a set of steps that move collective.amberjack in a more solid, usable and mostly, extensible tool.

We are also confident to introduce Windmill as the TTW tool for creating tutorials. Andrea Benetti from University of Ferrara is starting to extend it. Then we'll integrate it into a collective.amberjack.windmill package.

how could you get involved inTO the project?

If you are interested in contribution, the places where we meet are these:

• launchpad, for the project management (blueprints, bugs, etc.)
• coactivate, extremely useful for documentation through its wiki and for the mailing lists
• the code is obviously release on collective.

Otherwise, if you just want to use the system, pypi is your friend:

The attempt to use Deliverance on a Plone site which must also provide users all the functionality of the backend could be more difficult than expected.
Should be evaluated each case involving the opening of a popup or overlay javascript, because without the appropriate rules of match would get a beautiful Internal Server Error or a very nice "zoom effect" (in the popup will be reloaded the entire site) .

How to solve the problem?

Putting on top of our file rules.xml the match for all addresses that should not be filtered by Deliverance.

For the popup Related Items:

<match path="regex:^(.*/VirtualHostRoot|)/.*referencebrowser_popup$" abort="1" /> <match path="regex:^(.*/VirtualHostRoot|)/.*referencebrowser_popup$" abort="1" />

To view in a news  the image in original size:

<match path="regex:^(.*/VirtualHostRoot|)/.+/image_view_fullscreen" abort="1" /> <match path="regex:^(.*/VirtualHostRoot|)/.+/image_view_fullscreen" abort="1" />

For some of the basic tools of TinyMCE, including uploading files and images:

<match path="regex:^(.*/VirtualHostRoot|)/tinymce-upload$" abort="1" />

<match path="regex:^(.*/VirtualHostRoot|)/.+/plone(image|link)\.htm$" abort="1" />

<match path="regex:^(.*/VirtualHostRoot|)/.*/plugins/table/(table|row|cell|merge_cells)\.htm$" abort="1" />

<match path="regex:^(.*/VirtualHostRoot|)/.+/advanced/(source_editor|anchor)\.htm$" abort="1" />

Every time a new TinyMCE tool is enabled not forget to make sure it works properly ;)

Understood the principle, is easy to customize and improve the regular expression to fit our needs!

For a preamble for all who didn't know nothing about it, lets me say some words on the Italian law for accessibility: the so called Stanca Act.

The Italian Legislation on Accessibility force all newly created public websites to keep 22 requirements, mainly taken from the WCAG 1.0.

For how Plone is designed (trying to fulfil the WCAG at AA level) a lot of required work is just done (I really like when this happen)!

There are only 2 requirements that keep our head busy every time we develop a new site for an Italian public agency:

Requirement 1

The (X)HTML must follow the Strict DTD.

Requirement 10

"[...] associate data cells and header cells in data tables that have two or more logical levels of row or column headers."

For us the requirement 1 is a fight against the Transitional DTD of Plone (see also the #4379). Of course, this mean we are always forced to fix manually some Plone templates, but at the end after 4 year this become a well know job!

The real problem is the XHTML code that users put inside the WYSIWYG editor... this must provide us XHTML Strict code someway!

When Kupu was the Plone choice this was a difficult... sometimes our choice was to put a layer between the editor work and the end user, fixing the code using the uTidylib!

In the perfect world the WYSIWYG editor itself must return us the XHTML Strict code...

Again: the requirement 10 is also a WYSIWYG editor problem. Kupu is not helping us to add additional cell info on created tables.

Welcome TinyMCE

The future (but already available) WYSIWYG editor for Plone 4 is TinyMCE.

The output code of TinyMCE is "more strict" than the Kupu ones... only some minimal fixes are needed. If facts the only validation error found right now if the use of the type attribute for ordered and unordered list (not available in XHTML Strict).

We are keeping updated a TinyMCE branch you can download and test from the collective; it fix the 2 problems described.

First of all: it's not using the type attribute again, but instead it applies a CSS class. An additional small stylesheet make the rest. For details see changes.

The other missing feature is to help the editor to add more attribute to table cells and headers. The simpler solution from the W3C is to provide the scope attribute.

When I started this task I was sure that this was going to steal me a lot of time... but again TinyMCE was a nice surprise!

The patch applied is simple; for some reason TinyMCE support the scope natively but it's disabled (probably only in the Plone version?). As you can see in changes done, my work was very quick (and again: I like when this happen)!

And now?

• The first fix above is also valid for XHTML Transitional pages
• The new scope attribute feature can be useful also outside a Stanca Law environment.

So?

We proposed to merge those changes in the TinyMCE core!

Keep one eye on #115 and #131!