Cea mai scumpă greșeală dintr-un proiect Drupal nu e un bug, o interogare lentă sau un termen ratat. E un model de conținut care nu se potrivește cu felul în care funcționează organizația în realitate. Odată ce structura greșită ajunge în producție, fiecare pagină, fiecare obicei al editorilor și fiecare integrare care depinde de ea se construiesc peste ea, iar s-o schimbi mai târziu costă mult mai mult decât s-o faci bine din prima.
Partea tristă e că discuția care ar fi prevenit totul durează cam două zile. E exact discuția pentru care majoritatea proiectelor nu își fac niciodată timp.
Ce e de fapt un model de conținut
Uită pentru o clipă vocabularul Drupal. Un model de conținut e răspunsul la o întrebare foarte practică: ce fel de lucruri există pe site-ul ăsta și ce știe fiecare dintre ele despre sine?
Un portal de joburi știe despre joburi. Un job are un titlu, o companie, o locație, un interval salarial, un tip de contract, un termen-limită de aplicare și o descriere. O universitate știe despre cursuri. Un curs are un nume, o facultate, un nivel, o durată, o limbă de predare, o listă de condiții prealabile și o perioadă de înscriere. O editură specializată știe despre articole, autori și subiecte, și despre relațiile dintre ele.
În termeni Drupal, aici decizi tipurile de conținut, câmpurile, taxonomiile și relațiile dintre ele. E schița după care se construiește întregul site. Oricare dintre modelele astea iese greșit din prima dacă nu pune cineva, cu voce tare, întrebările potrivite.
Întrebările pe care nu le pune nimeni
La fiecare proiect nou insistăm pe o perioadă de modelare a conținutului înainte să înceapă orice design sau dezvoltare. Nu sună deloc spectaculos. Clienții se împotrivesc uneori (am plătit pentru design, putem vedea niște pagini?), iar noi rămânem pe poziție de fiecare dată. E munca care decide dacă restul proiectului merge lin sau cu chinuri.
Întrebările pe care le punem sunt simple, dar rareori apar într-un brief de proiect.
Cine introduce conținutul ăsta și ce informații are la îndemână? O echipă de marketing care scrie articole lungi lucrează altfel decât o echipă tehnică ce publică specificații de produs dintr-un tabel. Un comunicat de presă are un alt ciclu de viață decât o pagină de produs. Modelul trebuie să se potrivească cu ce intră în el, așa că pornim de la fluxul editorial, nu de la design. Cel mai rapid mod de a-l înțelege e să stai cu oamenii care vor folosi efectiv CMS-ul și să întrebi ce creează cel mai des, ce le ia cel mai mult timp și ce ar vrea să reutilizeze. Răspunsurile lor conturează tipurile de conținut mult mai mult decât orice wireframe.
Ce se leagă de ce? Dacă un eveniment are un speaker, și un speaker are o biografie, și biografia apare pe trei pagini, e o singură bucată de conținut refolosită sau trei copii care, cu timpul, o iau fiecare pe drumul ei? Răspunsul decide dacă peste șase luni editorii tăi vor blestema site-ul.
Ce se schimbă des, ce nu se schimbă niciodată? Un model de conținut ar trebui să separe părțile stabile ale arhitecturii informației de cele care se mișcă săptămânal. Amândouă au locul lor. Dar nu același loc.
Ce trebuie tradus și ce e valabil în orice limbă? Organizațiile multilingve descoperă aproape întotdeauna prea târziu că unele câmpuri ar trebui partajate între limbi (un cod de produs, de exemplu) și altele nu (o descriere de produs). Răspunsul corect trebuie prins în model din prima zi, nu cârpit ulterior.
Ce altceva din afacerea ta depinde de conținutul ăsta? Feeduri, exporturi, integrări, panouri de raportare, newslettere, materiale tipărite. Dacă vreunul dintre sistemele care preiau conținutul are nevoie de el într-o formă anume, modelul trebuie să respecte forma respectivă. Dacă afli târziu, s-ar putea să reintroduci de mână un munte de conținut.
Câteva reguli pe care le urmăm
După un număr bun de proiecte Drupal, ne-am oprit la câteva reguli de modelare care previn cele mai frecvente greșeli.
Separă structura de prezentare. Un marcaj de tip "recomandat" nu ar trebui să fie un tip de conținut. Ar trebui să fie un câmp boolean sau un termen de taxonomie. Tipurile de conținut reprezintă feluri fundamental diferite de conținut: un eveniment și un articol sunt tipuri diferite. Un articol și un articol recomandat sunt același tip, cu un câmp în plus.
Preferă referințele către entități în loc să dublezi conținutul. Dacă două tipuri de conținut folosesc aceleași informații despre autor, nu crea câmpuri de autor pe amândouă. Creează o entitate de autor și fă trimitere la ea. Când se schimbă biografia autorului, se actualizează peste tot deodată.
Denumește câmpurile după sens, nu după aspect. Un câmp numit "Text sidebar" se strică în momentul în care refaci designul și elimini sidebar-ul. Un câmp numit "Rezumat" funcționează oriunde apare. Numele câmpurilor ar trebui să descrie ce e conținutul, nu unde ajunge.
Planifică traducerea din prima zi. Dacă există cea mai mică șansă ca site-ul să fie multilingv, activează traducerea pe tipurile de conținut și pe câmpuri înainte să apară conținutul. Să adaugi traducerea după aceea, peste un model existent, e dureros și plin de capcane.
Costul ascuns al layout-urilor prea flexibile
Layout Builder și abordările bazate pe paragrafe oferă editorilor multă libertate. Pot aranja componente, adăuga coloane și construi un layout personalizat pentru fiecare pagină. Sună ideal până vezi ce iese de obicei în practică: fiecare pagină arată puțin altfel, coerența brandului se erodează, iar editorii ajung să piardă timp serios reconstruind același layout, de multe ori mai prost decât ar face-o un șablon, înainte de fiecare publicare.
Noi preferăm de regulă conținutul structurat, cu un set mai restrâns de opțiuni de layout. O pagină de eveniment are o structură definită: titlu, dată, locație, descriere, speakeri, link de înscriere. Editorul completează câmpurile, iar șablonul se ocupă de layout. E mai rapid pentru editori, mai coerent pentru brand și mai ușor de întreținut pentru dezvoltatori. Flexibilitatea nu e întotdeauna un avantaj. Uneori e o povară deghizată în autonomie.
Testează cu conținut real înainte de lansare
Ultimul și cel mai important pas e să umpli site-ul cu conținut real înainte să bați modelul în cuie. Nu lorem ipsum: conținut real de pe site-ul existent al clientului sau prima ciornă a conținutului nou. Conținutul real scoate la iveală probleme pe care textul de umplutură le ascunde: titluri prea lungi, descrieri care au nevoie de rich text, imagini cu proporții neașteptate și relații care trebuie să funcționeze în ambele direcții. Orele petrecute testând modelul cu conținut real sunt printre cele mai bine investite din tot proiectul, pentru că aduc corecturile la suprafață cât încă sunt ieftine.
Cum se simte, din interiorul organizației, un site bine modelat
Răsplata pentru un model făcut bine e ce ne povestesc clienții cel mai des, la ani buni după lansare. Aproape niciodată nu sună tehnic. Sună cam așa.
"Echipa mea poate publica un eveniment în trei minute acum. Înainte dura cincisprezece."
"Când am lansat în franceză, nu a trebuit să refacem nimic. Conținutul a mers pur și simplu."
"Platforma noastră de newsletter preia automat articolele recomandate în fiecare luni dimineață. Nimeni nu copiază nimic nicăieri."
"Când am adăugat o nouă linie de produse, nu a trebuit să vă sunăm."
Rezultatele astea nu vin dintr-un cod deștept. Vin dintr-un model de conținut care a înțeles organizația înainte ca organizația să se înțeleagă pe deplin pe sine.
Dacă site-ul tău actual e un chin de editat, aproape sigur ăsta e motivul
Dacă editorii din echipa ta se plâng de CMS ("nu găsesc niciodată câmpul potrivit", "ajung să editez HTML", "trebuie să lipesc același lucru în trei locuri"), aproape niciodată nu e CMS-ul de vină. E modelul de conținut de dedesubt. Vestea bună e că un model de conținut se poate audita, iar multe dintre problemele pe care le creează se pot repara fără să reconstruiești totul, dacă se uită la el, cu ochi proaspeți, cineva care a mai făcut asta.
Dacă site-ul pe care ți-l dorești există deocamdată doar în mintea ta, cu editori care se mișcă repede, integrări care merg fără bătăi de cap și conținut care ajunge peste tot unde e nevoie de el, spune-ne cu ce se ocupă organizația ta. Prima discuție e despre cum arată organizația ta, nu despre cum arată site-ul tău Drupal.