L’eccezione dell’homepage

Tutti vogliono una bella homepage. Non importa chi guida l’azienda, in che settore essa sia, quale sia il trend del momento nel design o quale CMS si usi: la homepage è il portone d’ingresso di un’azienda e le aziende vogliono homepage che riflettano le loro scintillanti mission e i loro contenuti.

Ovviamente qui è dove entriamo in gioco noi, i professionisti del web: identifichiamo i pattern nei contenuti e nel design dell’azienda, creiamo un sistema ordinato per gestire il sito, con il contenuto memorizzato in campi strutturati e con riferimenti incrociati alle tassonomie, trasformiamo design che fanno meravigliosi in template pattern carini, nei quali un CMS può automagicamente far fluire quel contenuto. Rilassatevi umani! I robot dei computer capiscono queste cose.

E, ovviamente, i robot guidano anche il contenuto della vostra homepage. Un tipo comune di homepage, che vedo molto spesso nel mio lavoro con organizzazioni no profit, ma che si può trovare in ogni settore, è un mix di contenuto in qualche modo statico ed esplicativo, con delle parti dinamiche popolate da un CMS con i contenuti pubblicati più di recente. Quando queste organizzazioni hanno poco budget, spesso senza un grande staff né risorse, sembra una buona idea mettere le parti statiche nel codice e automatizzare le parti dinamiche. In questo modo, lo staff non deve avere a che fare con le modifiche, gli aggiornamenti o le interfacce tecniche e l’organizzazione può concentrarsi sull’esecuzione del lavoro importante per aiutare le persone. Homepage: fatta.

Fino a che non arriva l’inevitabile richiesta: il board of directors ha bisogno di uno slider perché vogliono mettere in rilievo più di un post alla volta. Inoltre, vogliono che ciascuna slide sia in grado di mostrare un blog post o una pagina per le donazioni o una pagina “about” o il loro catalogo dei regali. Ed è importante per l’executive director che tutti i pezzi statici siano scritti bene e in maniera speciale per la homepage e i pezzi potrebbero aver bisogno di essere sistemati durante i mesi di picco delle raccolte fondi. Ed ecco che il mio semplice sistema di pubblicazione dell’homepage se n’è appena andato.

Probabilmente i robot non dovrebbero vincere#section1

Dopo aver fatto questa conversazione per circa 242 volte, mi sono resa conto che c’è un motivo per cui la homepage è quasi sempre una gigantesca eccezione rispetto al resto dell’ordinato sistema: è la pagina più umana sul sito, dove il potenziale aiuto dei robot dei computer collide con la disordinata realtà degli umani.

La homepage è l’elevator pitch dell’azienda, deve telegrafare le priorità e i valori di un’organizzazione il più succintamente possibile. Il dipartimento delle raccolte fondi, lo staff del programma e i membri del board potrebbero essere un po’ ansiosi riguardo all’essere sicuri che i propri interessi siano visibili in questo spazio così prezioso. Queste forze interne, o la politica delle organizzazioni partner o dei funders, avranno un’influenza su quello che viene presentato su un’homepage, anche se potrebbe non essere la scelta più logica per contenuto, design o struttura.

Invece di augurarsi il (sempre elusivo) Controllo Totale e Completo, è più utile accettare questa mania umana. Piuttosto che combatterla, costruiamo qualcosa di specifico per gestire meglio questa eccezione, in un modo che sia quella a minor probabilità di spezzarsi lungo il percorso.

Dei blob e dei chunk#section2

Ecco una homepage che sto attualmente ricreando per Small Can Be Big, un progetto no profit dell’agenzia di marketing Boathouse. Small Can Be Big lavora con delle charities della zona di Boston per far sì che le famiglie locali evitino di diventare senzatetto. Scomponiamola:

1. Hero area: l’organizzazione vuole essere in grado di mettere quello che desidera in questa zona. Questo contenuto e il suo design sono unici della homepage.
2. “How it Works”: tre punti veloci sul processo dell’organizzazione. Anche questi sono peculiari della homepage.

3. “How it Makes a Difference”: una lista di brevi highlights sull’impatto dell’organizzazione. Blurb molto simili a questi risiedono nella landing page “Impact” del sito e potrebbero essere richiamati automaticamente. L’amministratore dei contenuti, tuttavia, deve essere in grado di riscrivere questi blurb specificatamente per la homepage, così che siano unici.
4. Una form per iscriversi alla newsletter: questa form potrebbe essere usata anche altrove nel sito, quindi verrà salvata in un blocco o in una widget accessibile da tutto il sito e poi verrà mostrato sulla homepage e nelle altre pagine quando serve.
5. L’ultimo blog post: questo verrà popolato automaticamente.
6. Una call to action personalizzata con contenuto di supporto, solo per la homepage.

Quindi, qui abbiamo un elemento globale presente in tutto il sito (la form di iscrizione) e una regione sistematizzata, che si popola automaticamente (l’ultimo blog post). Come permettiamo a questa organizzazione di personalizzare gli altri pezzi della pagina?

Un modo per affrontare questa situazione è creare questa pagina in un singolo campo body e dare al cliente un WYSIWYG con il quale mantenerla. Questo offre la flessibilità definitiva, ma come sa chiunque abbia scritto una considerevole quantità di HTML, dare agli amministratori del contenuto un grande blob WYSIWYG può condurre a codice malfunzionante, elementi che non sono accessibili o semantici, problemi con la “responsiveness” della pagina e contenuto che non rientra nei vincoli del design. Questo può rapidamente portare a una homepage da due soldi (è un termine tecnico).

Un approccio migliore consiste nello spezzare la pagina in piccoli chunk WYSIWYG personalizzati (blocchi, pannelli o widget di testo personalizzate). Li si assembla nella homepage attraverso uno tra i metodi migliori che il vostro CMS vi mette a disposizione e il cliente mantiene ciascuno di questi e ogni piccola snippet nel suo blocco.

Il vantaggio è che la homepage viene spezzata nei componenti, rinforzando, almeno in parte, la separazione del contenuto dal suo layout e dal design. Per esempio, il pezzo “How it Makes a Difference” potrebbe essere costruito come quattro blocchi separati o dei widget di testo personalizzato che si sistemano gli uni accanto agli altri:

Lo svantaggio è la gestione più complicata nel tempo: i container che tengono insieme questi chunks sono tool generici, cuciti insieme in una visualizzazione front-end. Ogni chunk potrebbe essere mantenuto ad un diverso URL. Potrebbe essere difficile includere del testo di aiuto specifico. E molti dei piccoli bit nel backend potrebbero essere difficili da tracciare per gli amministratori del contenuto, specialmente se non ci sono linee guida editoriali e un solido piano di governance. Alla fine, la qualità della homepage, e del sito, cominciano a degradare.

Abbracciamo l’eccezione!#section3

Quello che sto facendo sempre di più è creare un tipo di contenuto che esiste con uno solo scopo: fungere da form strutturata per l’immissione e il mantenimento del contenuto della homepage. Può sembrare strano dalla prospettiva dell’architettura dell’informazione. I tipi di contenuto sono generalmente riservati ai pezzi di contenuto che condividono degli attributi in comune, implicando che ci sia più di una istanza per quel contenuto. Come disse uno dei miei colleghi quando lo proposi la prima volta: “Un intero tipo di contenuto per un unico pezzo di contenuto?! Non è questo lo scopo dei tipi di contenuto!”

Ma qui è esattamente il momento in cui dobbiamo controllare gli obiettivi della creazione di strutture di contenuto del CMS in prima istanza: i robot sono qui per servire gli umani, non il contrario. Se serve fare questa eccezione, abbracciamola piuttosto che combatterla. Una singola form per editare tutto il contenuto custom sulla homepage può rendere le cose più semplici all’amministratore dei contenuti e contribuire a rafforzare la coesione del design e la consistenza dei contenuti.

Nello scomporre il tipo di contenuto per la homepage di Small Can Be Big, ho cercato i contenuti logici e i pattern di design così da poter raggruppare i campi in maniera utile. Per esempio, i tre blurb “How it Works” sono lì per informare i donatori del modo in cui funzionano i loro contributi:

È logico che questo tipo di elementi stia su una homepage e probabilmente serviranno sempre per questo sito, così l’ho creata come lista di tre oggetti e li ho chiamati esattamente come quello che sono: How it Works. Nel CMS, ha questo aspetto:

Ho incluso il testo di aiuto su quale HTML vada in ciascun campo e un po’ di esempi di contenuto. Se l’homepage cambierà in futuro, questi campi potranno essere sistemati o cancellati e sostituiti con qualcosa d’altro. Ma se la struttura del contenuto rimane la stessa, il design e/o il layout possono cambiare facilmente per assegnare nuovi stili alla stessa lista di tre elementi. In ogni caso, il setup è flessibile.

La form di editing dell’homepage è la vostra ostrica#section4

Il modo in cui suddividete la homepage in un tipo di contenuto dipende dal tipo di contenuto e di design con cui state lavorando. Nell’esempio di Small Can Be Big, ho suddiviso la form stessa nei vari contenuti e nelle aree di design della homepage: la sezione della feature principale (hero), la sezione di impatto, etc. Questo rende la form molto meno travolgente da editare.

La suddivisione dipende anche dalle risorse in termini di staff del vostro cliente. Nel mio esempio, il cliente ha nello staff una persona tecnica dedicata all’editing del contenuto dell’homepage. Abbiamo collaborato con gli amministratori di contenuto attraverso tutto il processo di sviluppo: sappiamo che il content admin della homepage conosce bene HTML e quando gli abbiamo chiesto quali tool di editing volesse, non ha richiesto alcun WYSIWYG. Ho scritto un testo di aiuto per ricordargli quali elementi di HTML sono permessi ed attesi nel campo (se cercasse di mettervi un HTML più incasinato, verrebbe tolto dal CMS) e gli abbiamo dato un rapido esempio o reminder inline del contenuto che dovrebbe andarci.

Per un admin meno esperto dal punto di vista tecnico, potrei creare più campi invece che di meno. I campi potrebbero contenere icone, immagini e alt text. Potrei mettere degli editor WYSIWYG in ciascun campo di testo, personalizzati per il markup che ci aspettiamo. In alternativa potrei far sì che ogni elemento sia un campo: campi immagine con testo di aiuto chiaro e descrittivo per le icone, campi di semplice testo per gli header H3 e per i blurb di paragrafo. Poi manderei fuori quei valori in template HTML personalizzati, dandomi il completo controllo sul markup attorno al contenuto.

La form di edit della homepage è una fantastica opportunità per aggiungere degli elementi di UI utili per gli amministratori di contenuto. E anche un’ottima idea aggiungere un blocco di testo di aiuto generale, come ho fatto nell’esempio, linkando alla documentazione del sito. Potete inoltre mettere qui anche un link alla style guide del sito, se ne ha una, o aggiungere delle note di tono e voce.

Ovviamente, dipende solo dal vostro budget e dalla timeline del vostro progetto quanto decidete di spingere in là questa cosa. Se possibile, è saggio creare tempo nei budget di progetto continuativi per degli aggiustamenti regolari a queste personalizzazioni, per essere sicuri che continueranno ad essere utili agli amministratori di contenuto nell’utilizzo quotidiano. Ma anche aggiungere un po’ di struttura e un testo di aiuto può portarvi lontano.

Lasciate vincere gli umani#section5

Il mio lavoro è di mappare le disordinate comunicazioni umane nei computer system per far sì che sia più semplice per le persone gestire quelle comunicazioni. Questo significa che devo equilibrare il regno booleano del codice del computer con i bisogni di gran lunga più ambigui delle comunicazioni aziendali. Creando un’eccezione strutturata per la molto umana homepage, posso assicurare meglio la consistenza che desidero come developer dando contemporaneamente agli amministratori di contenuto la flessibilità di cui hanno bisogno.

Aggiungere più logica e struttura all’editing dell’homepage ha anche un altro beneficio: incoraggia le persone a valutare il significato del contenuto della loro homepage, rendendole semplicemente migliori. Piuttosto che concentrarci solo sul “wow!” visuale e mettere icone e copy “perché serve qualcosina lì”, una form di edit strutturata può costringere le persone a fare l’inventario di cosa c’è lì e a identificare lo scopo di quel “qualcosina”. Questo incoraggia la conversazione attorno al ruolo di homepage e impedisce che diventi un parcheggio carino soggetto ai capricci della boardroom.

L’eccezione della homepage è solo un esempio dei molti tipi di compromessi che gli esseri umani hanno bisogno nei sistemi codificati e strutturati che creiamo per loro. È il nostro lavoro adattare i sistemi di computer ai loro bisogni non il contrario. Se non lo facciamo, allora avranno vinto i signori dei robot. Se ci aspettiamo, pianifichiamo e addirittura celebriamo queste eccezioni umane incasinate ai nostri sistemi logici, ci avviciniamo alla creazione di un web che funziona sia per le persone sia per le macchine.

Illustrazioni: {carlok}