La battaglia per il campo body

Problemi a Chunkytown#section1

Questo approccio “fields-and-templates” funziona molto bene per quel contenuto che segue dei pattern prevedibili, come le pagine con le informazioni di un prodotto, le photo gallery e i podcast. È alla base del sistema di successo “Create Once, Publish Everywhere” (“Crea una volta, pubblica ovunque”) di NPR ed è difficile trovare un CMS o un tool di web publishing che non offra un qualche modo per modellare diversi tipi di contenuto.

Il Team Chunk, però, ha una debolezza mortale: quanto il testo narrativo è mischiato a dei media embedded, a dei call-out complessi o ad altro materiale ricco, i template strutturati cominciano ad avere dei problemi a tenere il passo.

Ne è un esempio perfetto MSNBC.com: come parte del suo redesign del 2013, il canale di news via cavo mise più enfasi sulla copertura di news approfondite e “web first”. Il design includeva molti moduli riutilizzabili che potevano essere posizionati su pagine gestite via template: video con playlist che li accompagnano, photo gallery, widget per le votazioni e teaser per gli articoli correlati. Quella standardizzazione portò con sé tutti i benefici della modellazione del contenuto di un CMS: rese il design più consistente, semplificò il processo di riutilizzo degli elementi “rich media” in storie diverse e fece sì che le regole CSS responsive rimanessero gestibili.

Una “news story” di MSNBC, in cui gli elementi “rich media” devono apparire in punti specifici nelle storie ed includere caption, titoli, link correlati, etc.

Sfortunatamente, i reporter e gli editor insistettero che questo metodo avrebbe paralizzato il loro lavoro: avevano bisogno di mischiare più video, una gallery e una votazione o vari teaser da articoli collegati tra loro, in punti specifici di ciascun articolo. Creare questi elementi in campi separati del CMS o in pezzi autonomi di contenuto avrebbe reso più semplice il loro salvataggio e il loro rimescolamento. Tuttavia, fare affidamento su template CMS basati su regole per mostrarli avrebbe anche rotto le loro connessione alle frasi, ai paragrafi e alle sezioni specifiche che avrebbero dovuto migliorare.

Questo è il modo in cui il markup complesso si fa strada nel campo body di un articolo. Ben presto, si aggiungeranno dei tool WYSIWYG per aiutare gli editori con limitate conoscenze di HTML. Prima che qualcuno si renda conto di cosa sta succedendo, esplode l’uso di markup orientato alla presentazione. Si rompono i layout mobile e il compito già arduo del riutilizzo di contenuto cross-channel diventa ancora più difficile.

C’è un problema comune in un blog post con dei tweet “embedded”, in una recensione comparativa che illustra ciascun prodotto con una photo gallery e in una storia che richiama del materiale a supporto da un articolo precedente: l’approccio “fields-and-templates” non funziona per queste piccole sacche della struttura.

Perché il “clean markup” non aiuta#section2

Se siete cresciuti durante le WYSIWYG Wars, quando strumenti come Adobe PageMill e la feature “Save to Web” di Microsoft Word spruzzavano in internet markup terrificante, potreste pensare che un markup HTML più pulito sia la risposta a questo problema. Uccidi quegli attributi style inutili, assicurati che i tag <p> siano usati al posto dei <br />, usa i tag <ul> in maniera appropriata, presta attenzione ai nomi che scegli per le classi CSS e le cose si sistemeranno!

Il markup pulito e semantico è importante, ma non risolverà problemi strutturali complessi come il bisogno della MSNBC di inserire widget nel testo della narrazione. Abbiamo degli elementi stacanovisti come ul, div e span; degli strumenti di precisione come cite, table e figure e dei nuovi elementi container di HTML5 come section, aside e nav, ma a meno che il nostro contenuto sia davvero così semplice come una citazione senza attribuzione o una immagine con float, avremo bisogno di layour di elementi annidati e di classi CSS per catturare quello che vogliamo davvero dire.

Immaginate di voler inserire una semplice photo gallery in un articolo. Il suo markup potrebbe essere pulito e semanticamente corretto, ma il fatto che la galleria abbia un titolo, tre foto, un link ad una pagina dedicata e una caption? Queste sono le decisioni di design che potrebbero cambiare in futuro e noi dobbiamo separarle dalla mappatura del markup del nostro contenuto in HTML.

<aside class="gallery">
  <h1><a href="gallery1.html">Gallery Title!</a></h1>
  <figure>
    <a href="photo1.html"><img src="photo1.jpg" /></a>
    <a href="photo2.html"><img src="photo2.jpg" /></a>
    <a href="photo3.html"><img src="photo3.jpg" /></a>
    <figcaption>Custom caption</figcaption>
  </figure>
</aside>

Il problema, comunque, non è ristretto all’industria editoriale: il mio team, recentemente, ha incontrato delle sfide simili durante la realizzazione di un portale di una compagnia di assicurazioni sanitarie per il suo dipartimento Risorse Umane (HR). La maggior parte del contenuto sul sito da 50.000 pagine includeva istruzioni step-by-step complesse, step speciali per tipi specifici di impiegati o call-out appropriati per lavoratori di un certo stato ma non di un altro. Anche con un editor WYSIWYG, le strutture HTML necessarie erano troppo complesse da creare per gli utenti aziendali del sito.

Il punto centrale del problema è un disaccoppiamento del vocabolario. Sebbene l’HTML standard sia sufficientemente ricco perché un designer possa rappresentarci del contenuto complesso, non è sufficientemente preciso per descrivere e memorizzare il contenuto in maniera indipendente dalla presentazione. Questo è il motivo per cui gli strumenti WYSIWYG possono peggiorare il problema: piuttosto che schermare i creatori di contenuto dalla complessità del markup, rendono più semplice descrivere il contenuto usando il vocabolario sbagliato.

Ora, nel tentativo di combinare i requisiti di un design multi-device con narrazioni complesse e arricchite da contenuti multimediali, ci scontriamo contro il muro. L’approccio a pezzi, “fields-and-template” che abbiamo sviluppato non ci salverà dal disaccoppiamento tra il nostro contenuto e i tool descrittivi di HTML.

Nel frattempo, nel mondo di XML…#section3

Sebbene i campi e i template siano riusciti a dominare i tool di web publishing, il mondo XML ha passato gli ultimi 15 anni circa a sviluppare un approccio alternativo. Piuttosto che suddividere il contenuto in campi per riassemblarlo in seguito, la comunità di XML adotta documenti fluidi basati sul markup. Per catturare una struttura significativa ed evitare i trabocchetti della presentazione “browser-specific” di HTML, definiscono delle collezioni di tag di markup con uno scopo preciso per diversi progetti e applicazioni. È un approccio versatile che ha incrociato il suo percorso con quello del mondo dell’editoria web: lo standard XHTML è solo HTML definito come uno schema XML.

Lo standard Darwin Information Typing Architecture, meglio noto come DITA, è un esempio maturo di questo approccio. Sviluppato da IBM e annunciato nel 2001, DITA fu creato dalla community della documentazione tecnica. Nel lontano 2005, Adobe lo usò per memorizzare e gestire i manuali dei software della Creative Suite, più di 100.000 pagine con illustrazioni, cross-reference e metadati complessi, il tutto in 14 lingue. Sia l’edizione cartacea sia quella online furono generate dallo stesso insieme di files DITA.

Il cuore di DITA è un famiglia di Schema XML standard che definiscono un ricco vocabolario di elementi del contenuto. I tag compatibili con HTML come <ol> e <p> vengono usati per una semplice formattazione, ma lo standard definisce anche centinaia di ulteriori tag e proprietà che descrivono i concetti più complessi. Inoltre, include norme per delle “specializzazioni”: vocabolari add-on per un dato settore o progetto.

<task id="signup">
  <title>Signing up for health insurance</title>
  <taskbody>
    <steps>
      <step>List your dependents</step>
      <step>Gather past medical information</step>
      <step>Fill out forms 21a, 39b, and 92c</step>
      <step audience="retail">
          Hand in your paperwork to a supervisor
      </step>
      <step audience="corporate">
          Deliver your paperwork to the HR office
      </step>
    </steps>
  </taskbody>
</task>
<p conref="../boilerplate.xml#disclaimer">
  This text will be replaced by the boilerplate legal disclaimer.
</p>

Una volta che questi documenti semanticamente precisi sono stati creati, è necessario uno step di trasformazione per trasformare il contenuto strutturato nell’output finale. Un tool per il web publishing potrebbe leggere una directory di files DITA XML, sostituire gli elementi segnaposto con il testo cui fanno riferimento, espandere i tag personalizzati in markup HTML con degli stili, togliere il testo destinato specificatamente ai manuali stampati e così via.

Questo approccio non è privo di svantaggi. Gestire grandi collezioni di articoli e documenti correlati richiede che gli utenti che ne fanno l’editing capiscano le sfumature delle relazioni specifiche e il modo in cui influenzano il prodotto finale. Sebbene il più semplice schema DITA sia simile a HTML, altre variazioni aggiungono centinaia di tag e proprietà “special-purpose”.

Nel più ampio mondo del web publishing, potrebbe essere necessaria più personalizzazione per ottenere gli stessi benefici. Sebbene il contenuto semanticamente ricco sia più pulito e più semplice da ridestinare, creare dei tool editoriali e dei processi di pubblicazione usabili sulle basi di DITA può essere tanto scoraggiante quanto realizzare un complesso sito web multicanale.

Il meglio di entrambe i mondi#section4

La buona notizia è che non dobbiamo convertire tutti i nostri progetti in XML per imparare dalla saggezza accumulata da queste comunità. Nonostante le “toolchain” che sono state create attorno a questi approcci vadano strette agli strumenti e ai workflow dell’odierno maturo sviluppo web, possiamo usare i loro principi nei nostri progetti.

Mettete il significato nel body, non l’aspetto#section5

Quando nel testo della narrazione appaiono delle complesse strutture di markup, riducetele all’osso. Sostituite i complessi stili con dei tag personalizzati che descrivano il loro significato preciso, come <warning type="hardware">Non spegnere il server!</warning>. Quando un nuovo tag non è appropriato, usate degli attributi personalizzati. L’attributo audience di DITA ne è un buon esempio. Può essere applicato a molti diversi tipi di elementi, ma metterlo nell’attributo class di cui spesso si abusa in CSS ne confonderebbe il significato.

Elementi più complicati del campo body, come le gallerie con più immagini o gli inserimenti di media pieni di metadati, dovrebbero essere suddivisi in campi di contenuto separati. Se devono essere riutilizzati tra più pezzi di contenuto, rendeteli item di contenuto indipendenti in un CMS. Invece di fare affidamento su template basati su regole per posizionarli, comunque, usate dei segnaposto come <gallery id="1" /> e <teaser article="82" rel="rebuttal" /> proprio all’interno dei campi della narrazione.

Questo approccio fa diventare un articolo o un post una specie di manifesto, con i campi della narrazione come “Body” e “Riassunto” che fungono da poliziotti del traffico per la collezione di elementi supportati propriamente separati. In seguito, nell’output, possono essere rimessi insieme.

Create tool editoriali per gli stessi elementi significativi#section6

Gli editor e i creatori che lavorano con contenuto complesso hanno bisogno di strumenti per manipolare il vocabolario nativo del contenuto, non il design visuale finale o le sfumature specifiche del browser di HTML. Recentemente, Wikipedia ha presentato per la prima volta un assistive editing tool che aiuta i nuovi utenti a navigare nella complessità del contenuto del sito. Offre un insieme limitato di strumenti di formattazione, ma dà agli editor l’accesso con un click agli standard del markup specifico di Wikipedia, come le citazioni inline, il testo boilerplate e le call per le revisioni editoriali.

Screenshot del rich-text editor di Wikipedia, con degli assistive tools per il markup specifico dei Wiki

Questi tipi di decisioni non sono universali: sono create su misura per le peculiarità del contenuto di uno specifico progetto. Disabilitare tutti i trag HTML tranne quelli proprio di base e aggiungere pulsanti “one-click” per gli elementi custom di un sito può trasformare un editor WYSIWYG comune in uno strumento “structure-friendly”. È anche il modo migliore per evitare il disordine nel markup derivante dal cliccare pulsanti finché non sembra giusto.

Trasformare il contenuto perché si abbini al design#section7

Quando viene il momento di pubblicare il contenuto, possiamo trasformare questi tag e segnaposto personalizzati nel formato finale di destinazione. Se il design cambia, devono solo essere fatte delle modifiche nel codice o nei template che trasformano il markup, non in ogni singolo pezzo di contenuto in cui appaiono le strutture.

Inoltre, si possono applicare trasformazioni diverse agli elementi personalizzati a seconda del contesto. L’elemento <gallery> citato prima potrebbe essere sostituito da più immagini sottotitolate e con attribuzione di credits per la maggior parte dei browser web. Sui dispositivi mobile soggetti a vincoli di banda, una singola immagine thumbnail e i link all’intera galleria potrebbero essere inseriti al suo posto. Si possono prendere decisioni adeguate al contesto per i riassunti delle email, per le API del contenuto di partner o per i feed RSS: ciascuno di questi non è altro che un passo di trasformazione alternativo.

Questo processing non deve per forza avvenire lato server. Tool client-side come jQuery e AngularJS possono essere usati per applicare dei comportamenti complessi basandosi su attributi personalizzati, assegnando stile ed interazione con elementi custom, sostituire i segnaposto con markup standard o fare “lazy-load” di media adeguati alle esigenze di un device.

La notizia più bella è che oggi è già possibile#section8

Questa triade di tecniche (uso di elementi e proprietà custom che rappresentino il significato del contenuto, trasformarlo in HTML in output ed assicurarsi che i tool di editing condividano lo stesso vocabolario) ha già cominciato a muoversi nel mondo del web publishing.

Gli “Short Tags” di WordPress sono una semplice applicazione di questa tecnica e i plugin di terze parti possono presentare agli editor un insieme personalizzato di tag segnaposto realizzati in base alle loro necessità. Sebbene l’uso da parte di WordPress di segnaposto con le parentesi come

Nessun evento imminente

e renda il processing lato client di questi tag più difficile, l’approccio che ne è alla base è lo stesso. Gli shortcode possono suddividere elementi complessi o riutilizzabili in campi ed entità separate, per poi posizionarli all’interno del campo body.

EZPublish, un CMS basato su PHP molto popolare, permette di memorizzare il contenuto come XML piuttosto che come HTML. Gli sviluppatori possono impostare dei tag personalizzati le cui proprietà e il cui contenuto viene mappato in dei template per l’output. Sebbene non sia automatico, questi tag personalizzati possono essere integrati nei tool di editing nativi di EZPublish, così che i creatori di contenuto non debbano usare del puro markup per inserirli.

<custom name="about_author" photo="author.jpg" user_account="77" >
The author wrote this article over a long holiday break, and regrets any eggnog-induced errors.
</custom>

Drupal 8, attualmente in via di sviluppo, avrà un il tool WYSIWYG CKEditor nativo. Sarà pre-configurato con un insieme minimo di tag HTML, ma userà i data attributes di HTML5 per memorizzare proprietà aggiuntive come le caption, i suggerimenti di layout e altro sugli elementi semplici. Quando viene reso il contenuto, i text filter di Drupal lo trasformeranno nella rappresentazione finale: classi CSS, tag <figcaption> e così via. Gli utenti possono gestire tale complessa informazione usando i tool visuali di CKEditor invece del semplice markup, ma memorizzando contenuto di precisione e ottenendo in output dell’HTML semantico come comportamento di default.

Un futuro radioso#section9

Questo approccio al contenuto strutturato non farà sempre affidamento su tool di pubblicazione web complessi. Molti standard relativi ad HTML5, raggruppati sotto la categoria ombrello dei Web Components, alla fine renderanno possibile fare queste trasformazioni nel browser stesso. L’abilità di definire degli elementi personalizzati ci porterà più vicini alla flessibilità del vocabolario di XML, i template HTML supportati dai browser saranno in grado di sostituire al volo quegli elementi con markup “representational” più complesso e Shadow DOM darà ai designer un modo per provare in “sandbox” le complesse interazioni JavaScript e CSS all’interno di quegli elementi personalizzati.

Il supporto dei browser per questi comportamenti è chiaramente irregolare, ma strumenti quali Polymer sono pensati proprio per colmare queste lacune. Nel frattempo, possiamo ancora dipendere dagli elementi HTML esistenti, migliorati con i data attributes per sostituire quelli personalizzati. Sebbene dobbiamo ancora fare il lavoro per trasformarli, trovano un compromesso tra un preciso vocabolario su misura del contenuto e un markup pulito e browser-friendly.

Quali sono i prossimi passi?#section10

Usare questo approccio “narrative-friendly” verso il contenuto strutturato non è un gioco da ragazzi: i creatori di siti, i content strategist e i designer devono comprendere quello che succede all’interno del campo body, non solo i pezzi presi dal database che gli stanno intorno. Quali pattern nel contenuto devono avere dei semplici stili e quali si meritano un proprio tag personalizzato? Quali possiamo presumere che rimangano consistenti e per quali dovremmo prendere in considerazione dei cambi in futuro? Il nostro processo di pianificazione deve cominciare rispondendo a queste domande.

Inoltre, gli strumenti di editing del contenuto devono essere realizzati su misura per riflettere queste decisioni. Troppi utenti sono abituati ai tool WYSIWYG “Dreamweaver nel campo body” orientati alla presentazione e farli tornare nella terra del puro markup è la strada giusta verso il disastro. Sebbene l’insieme degli attuali tool WYSIWYG per il web possa essere personalizzato, accade raramente che li si possa modificare davvero per far sì che siano adatti al vocabolario del contenuto di un sito quando incombono le scadenze.

Tuttavia il riscontro potrebbe essere incredibile. Design più ricchi e flessibili possono coesistere con la richiesta di editoria multicanale: i cambiamenti futuri al design possono svicolare il processo laborioso di sgrossare vecchi agglomerati di contenuto e tool più semplici ed efficienti possono aiutare gli editori e gli autori a produrre contenuto migliore più rapidamente. Possiamo mettere al sicuro il campo body per le future generazioni combinando il meglio di XML e il contenuto web strutturato.

Illustrazioni: {carlok}