{"id":594,"date":"2016-03-02T20:57:33","date_gmt":"2016-03-02T19:57:33","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/eccezione-della-homepage\/"},"modified":"2016-03-02T20:57:33","modified_gmt":"2016-03-02T19:57:33","slug":"eccezione-della-homepage","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/eccezione-della-homepage\/","title":{"rendered":"L’eccezione dell’homepage"},"content":{"rendered":"
\n

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 \u00e8 il portone d’ingresso di un’azienda e le aziende vogliono homepage che riflettano le loro scintillanti mission e i loro contenuti.<\/p>\n

Ovviamente qui \u00e8 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\u00f2 automagicamente far fluire quel contenuto. Rilassatevi umani! I robot dei computer capiscono queste cose.<\/p>\n

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\u00f2 trovare in ogni settore, \u00e8 un mix di contenuto in qualche modo statico ed esplicativo, con delle parti dinamiche popolate da un CMS con i contenuti pubblicati pi\u00f9 di recente. Quando queste organizzazioni hanno poco budget, spesso senza un grande staff n\u00e9 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\u00f2 concentrarsi sull’esecuzione del lavoro importante per aiutare le persone. Homepage: fatta.<\/p>\n

Fino a che non arriva l’inevitabile richiesta: il board of directors ha bisogno<\/em> di uno slider perch\u00e9 vogliono mettere in rilievo pi\u00f9 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 \u00e8 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’\u00e8 appena andato.<\/p>\n<\/div>\n

\n

Probabilmente i robot non dovrebbero vincere<\/h2>\n

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

La homepage \u00e8 l’elevator pitch dell’azienda, deve telegrafare le priorit\u00e0 e i valori di un’organizzazione il pi\u00f9 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\u00ec 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\u00f9 logica per contenuto, design o struttura.<\/p>\n

Invece di augurarsi il (sempre elusivo) Controllo Totale e Completo, \u00e8 pi\u00f9 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\u00e0 di spezzarsi lungo il percorso.<\/p>\n<\/div>\n

\n

Dei blob e dei chunk<\/h2>\n

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

\"Uno<\/div>\n
    \n
  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.<\/li>\n
  2. \u201cHow it Works\u201d: tre punti veloci sul processo dell’organizzazione. Anche questi sono peculiari della homepage.<\/li>\n
    \"no<\/div>\n
  3. \u201cHow it Makes a Difference\u201d: una lista di brevi highlights sull’impatto dell’organizzazione. Blurb molto simili a questi risiedono nella landing page \u201cImpact\u201d 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\u00ec che siano unici.<\/li>\n
  4. Una form per iscriversi alla newsletter: questa form potrebbe essere usata anche altrove nel sito, quindi verr\u00e0 salvata in un blocco o in una widget accessibile da tutto il sito e poi verr\u00e0 mostrato sulla homepage e nelle altre pagine quando serve.<\/li>\n
  5. L’ultimo blog post: questo verr\u00e0 popolato automaticamente.<\/li>\n
  6. Una call to action personalizzata con contenuto di supporto, solo per la homepage.<\/li>\n<\/ol>\n

    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?<\/p>\n

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

    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.<\/p>\n

    Il vantaggio \u00e8 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 \u201cHow it Makes a Difference\u201d potrebbe essere costruito come quattro blocchi separati o dei widget di testo personalizzato che si sistemano gli uni accanto agli altri:<\/p>\n

    \"Uno<\/div>\n

    Lo svantaggio \u00e8 la gestione pi\u00f9 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\u00e0 della homepage, e del sito, cominciano a degradare.<\/p>\n<\/div>\n

    \n

    Abbracciamo l’eccezione!<\/h2>\n

    Quello che sto facendo sempre di pi\u00f9 \u00e8 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\u00f2 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<\/a>, implicando che ci sia pi\u00f9 di una istanza per quel contenuto. Come disse uno dei miei colleghi quando lo proposi la prima volta: \u201cUn intero tipo di contenuto per un unico pezzo di contenuto?! Non \u00e8 questo lo scopo dei tipi di contenuto!\u201d<\/p>\n

    Ma qui \u00e8 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\u00f2 rendere le cose pi\u00f9 semplici all’amministratore dei contenuti e contribuire a rafforzare la coesione del design e la consistenza dei contenuti.<\/p>\n

    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\u00ec da poter raggruppare i campi in maniera utile. Per esempio, i tre blurb \u201cHow it Works\u201d sono l\u00ec per informare i donatori del modo in cui funzionano i loro contributi:<\/p>\n

    \"Uno<\/div>\n

    \u00c8 logico che questo tipo di elementi stia su una homepage e probabilmente serviranno sempre per questo sito, cos\u00ec 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:<\/p>\n

    \"Uno<\/div>\n

    Ho incluso il testo di aiuto su quale HTML vada in ciascun campo e un po’ di esempi di contenuto. Se l’homepage cambier\u00e0 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 \u00e8 flessibile.<\/p>\n<\/div>\n

    \n

    La form di editing dell’homepage \u00e8 la vostra ostrica<\/h2>\n

    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.<\/p>\n

    \"Uno<\/div>\n

    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\u00f9 incasinato, verrebbe tolto dal CMS) e gli abbiamo dato un rapido esempio o reminder inline del contenuto che dovrebbe andarci.<\/p>\n

    Per un admin meno esperto dal punto di vista tecnico, potrei creare pi\u00f9 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\u00ec 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.<\/p>\n

    La form di edit della homepage \u00e8 una fantastica opportunit\u00e0 per aggiungere degli elementi di UI utili<\/a> 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.<\/p>\n

    Ovviamente, dipende solo dal vostro budget e dalla timeline del vostro progetto quanto decidete di spingere in l\u00e0 questa cosa. Se possibile, \u00e8 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\u00f2 portarvi lontano.<\/p>\n<\/div>\n

    \n

    Lasciate vincere gli umani<\/h2>\n

    Il mio lavoro \u00e8 di mappare le disordinate comunicazioni umane nei computer system per far s\u00ec che sia pi\u00f9 semplice per le persone<\/em> gestire quelle comunicazioni. Questo significa che devo equilibrare il regno booleano del codice del computer con i bisogni di gran lunga pi\u00f9 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\u00e0 di cui hanno bisogno.<\/p>\n

    Aggiungere pi\u00f9 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<\/em>. Piuttosto che concentrarci solo sul \u201cwow!\u201d visuale e mettere icone e copy \u201cperch\u00e9 serve qualcosina l\u00ec\u201d, una form di edit strutturata pu\u00f2 costringere le persone a fare l’inventario di cosa c’\u00e8 l\u00ec e a identificare lo scopo di quel \u201cqualcosina\u201d. Questo incoraggia la conversazione attorno al ruolo di homepage e impedisce che diventi un parcheggio carino soggetto ai capricci della boardroom.<\/p>\n

    L’eccezione della homepage \u00e8 solo un esempio dei molti tipi di compromessi che gli esseri umani hanno bisogno nei sistemi codificati e strutturati che creiamo per loro. \u00c8 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.<\/p>\n

    Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    I sistemi strutturati, automatici, sono eccellenti per gestire il contenuto in maniera efficiente ma non sono cos\u00ec grandiosi nell’accomodare i cambiamenti umani di tali contenuti. D’altro canto, WYSIWYG liberi per tutti portano a inconsistenze e rotture. Gli stakeholder e gli amministratori di contenuto hanno bisogno di flessibilit\u00e0 e controllo, specialmente quando si tratta della super-importante homepage. Cosa deve fare un sito Web? Johanna Bates suggerisce di abbracciare una soluzione per una homepage people-friendly all’interno delle nostre architetture guidate dai robot.<\/p>\n","protected":false},"author":818,"featured_media":7000785,"comment_status":"open","ping_status":"open","template":"","categories":[246,254,140,277],"tags":[],"coauthors":[466],"class_list":["post-594","article","type-article","status-publish","has-post-thumbnail","hentry","category-architettura-dell-informazione","category-content-strategy","category-numero-122-02-marzo-2016","category-web-strategy"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/594","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=594"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000785"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=594"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=594"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=594"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}