Modelarea conținutului cu Jekyll

Nu este chiar un subiect nou, dar în ultima vreme am avut motive să revadă abilitatea de modelare a conținutului în munca echipei mele. Experiența noastră a atins un punct în care limitările modului în care practicăm încep să devină clare. Problema noastră cea mai comună este că oamenii tind să se lege și modelele lor mentale de o platformă aleasă și de convențiile acesteia.

În loc să-i învățăm pe oameni cum să modeleze conținutul, ajungem să-i învățăm cum să modeleze conținutul în Drupal sau cum să modeleze conținutul în WordPress. Dar aș prefera să o abordăm concentrându-ne pe cel mai bun interes al utilizatorilor, indiferent de platforma în care va ajunge conținutul menționat.

Citiți suplimentare despre SmashingMag:

• Creați un blog cu pagini Jekyll și GitHub
• De ce generatoarele statice de site-uri web sunt următorul lucru important
• Generatoare statice de site-uri revizuite: Jekyll, Middleman, Roots, Hugo
• Automatizarea dezvoltării bazate pe ghiduri de stil

Această linie de gândire m-a adus înapoi la o idee de care am devenit puțin obsedat, și anume că atunci când trebuie să creăm un artefact pentru a comunica anumite idei unui client, procesul merge aproape întotdeauna mai bine atunci când acel artefact este la fel de aproape. posibil la un site web real în loc de o imagine a unui site web sau un PDF plin de diagrame.

Astfel, întrebarea pe care am ajuns să mi-o pun: a existat un instrument pe care l-aș putea folosi pentru a ajuta oamenii să modeleze rapid conținutul într-o manieră independentă de platformă și, în același timp, să construiască un artefact care era ideal pentru comunicarea intenției unui client sau unei echipe?

O teorie la nivel înalt a modelării conținutului

Să ne abatem puțin înainte de a ajunge în Jekyll. Cred că puteți elimina toate convențiile și limbajul specific platformei din discuția despre modelarea conținutului și le puteți defini ca un sistem din trei părți:

1. Ideea de bază este aceea a unui obiect : o unitate de conținut care se ține împreună pe un site. De exemplu, o postare pe blog sau o persoană ar fi un obiect pe un site.
2. Obiectele au atribute care le definesc . O postare pe blog poate avea un titlu, un corp de conținut, un autor. O persoană poate avea un nume, o fotografie, o biografie.
3. Obiectele au relații care determină unde ajung pe un site , iar aspectele au o logică care definește ce atribute ale unui obiect sunt utilizate și unde. Exemplul nostru de obiect de postare de blog este conectat la un obiect persoană, deoarece autorul acestuia este o persoană. Trimitem numele autorului și un link către profilul său pe pagina de postare, iar biografia lor completă este afișată pe pagina de profil.

Am vrut să creez un sistem care să respecte ideile de nivel înalt pe care le-am conturat, dar să permită echipei libertatea de a crea atribute și relații așa cum credea de cuviință, fără a-și face griji pentru ideile specifice anumitor platforme. În schimb, s-ar putea concentra pe definirea conținutului pe baza a ceea ce este mai bine pentru utilizatori . Și se dovedește că Jekyll are caracteristicile pentru a face acest lucru posibil.

Intră Jekyll

Jekyll este un cadru static de blogging. Și înainte de a vă îndrepta către secțiunea de comentarii, da, sunt conștient că este corect să o privim ca pe o platformă în sine. Cu toate acestea, are câteva avantaje față de ceva precum Drupal sau WordPress.

Jekyll ia în serios simplitatea. Nu are o bază de date, bazându-se în schimb pe fișiere plate și pe niște etichete de șabloane Liquid care generează HTML simplu vechi. Lichidul este limitat, simplu și extrem de ușor de citit de om. Am descoperit că pot arăta cuiva un șablon construit cu niște etichete Liquid și, atâta timp cât au puțină experiență cu codul front-end, înțeleg ce face șablonul.

Ceea ce este bine în acest sens este că nu trebuie să arătăm cuiva cum să ruleze o bază de date, cum să-și conecteze șabloanele la ea, cum să configureze zona de administrare a CMS-ului pentru a lucra cu șabloanele lor și așa mai departe. În schimb, putem instala Jekyll și învățam cum să porniți un server. Dacă utilizatorul este pe un Mac, există o șansă excelentă ca acesta să fie un proces de două minute care funcționează doar prima dată când îl încercăm.

De asemenea, Jekyll nu forțează o mulțime de convenții în gâtul utilizatorului. Aveți libertatea de a crea structura de fișiere și pipeline de active preferate, de a vă stabili propriile relații între fișiere și de a scrie markup în modul în care vă place cel mai mult. Câteva convenții pe care le are sunt ușor de reconfigurat pentru a se potrivi stilului tău.

Utilizarea colecțiilor pentru a crea și a conține obiecte

Deși este încă considerată o caracteristică experimentală, Jekyll are ceva numit colecții care ne vor permite să creăm sistemul pe care îl descriu.

Practic, creați un folder și îl denumiți după tipul de obiect pe care îl creați. Apoi adăugați fișiere în acel folder și fiecare fișier reprezintă un obiect din acea colecție. Odată ce aveți obiecte, puteți crea atribute pentru ele folosind YAML la începutul fiecărui fișier. YAML este o sintaxă care vă permite să definiți perechi cheie/valoare care stochează cu ușurință informații.

Ceea ce este frumos la acest sistem este cât de incredibil de simplu este. Totul poate fi citit de om și funcționează într-un mod ușor de învățat pentru un utilizator nou. În loc să creați multă documentație despre cum ar trebui cineva să creeze conținut și relații în sistemul final, puteți să o creați. Designerii pot vedea care sunt obiectele și atributele lor, astfel încât să își poată planifica sistemul de proiectare. Dezvoltatorii front-end au un site web funcțional cu care să își proiecteze marcajul și CSS.

Deoarece nu sunt obligați să folosească un anumit sistem sau convenție, pot folosi doar cel pe care îl preferă sau convențiile platformei finale pentru proiect. Și dezvoltatorii back-end pot determina cu ușurință intenția designerului atunci când transferă șabloane și logica în orice CMS pe care decid să-l folosească, deoarece este deja scris pentru ei.

Să construim un site simplu cu obiecte și relații

Dacă o să luăm această idee, va trebui să creăm un site simplu Jekyll și apoi să ne construim obiectele și relațiile. Dacă doriți să vedeți produsul final, îl puteți lua din acest depozit GitHub. (Notă: va trebui să utilizați terminalul pentru unele dintre acestea, dar este o utilizare destul de simplă, promit.)

Instalarea Jekyll

Dacă sunteți pe un Mac, acest lucru este destul de ușor. Ruby este deja instalat, trebuie doar să instalați Jekyll. Deschideți terminalul și tastați:

 gem install jekyll

Aceasta va instala bijuteria Jekyll Ruby și dependențele sale. Odată ce s-a terminat de alergat, asta este: îl ai pe Jekyll.

Configurarea site-ului dvs

Acum trebuie să începem o schelă Jekyll. Îmi stochez toate proiectele web într-un folder de pe Mac numit Site-uri , în folderul de pornire. Deci mai întâi trebuie să navighez la el cu:

 cd ~/Sites

Apoi pot genera un folder cu fișierele și structura corespunzătoare cu această comandă:

 jekyll new my-new-site

Puteți înlocui „noul-site-ul meu” cu ceea ce doriți să numiți proiectul dvs. Ceea ce veți obține este un folder cu acest nume și toate fișierele potrivite din el.

Deschideți Finder și navigați la noul folder pentru a vedea ce se află în interior. Ar trebui să vezi așa ceva:

Deoarece nu avem nevoie de tot ce ne oferă Jekyll, vom șterge mai întâi câteva fișiere și foldere. Să aruncăm /_includes , /_posts , /_sass , about.md și feed.xml .

Configurare

Acum vom configura configurațiile la nivel de site. Deschideți _config.yml . Sunt o grămadă de chestii introductive acolo. Îl voi șterge și îl voi înlocui cu configurațiile mele preferate. Iată noua configurație pentru acest proiect:

 permalink: pretty collections: projects people

Am făcut astfel încât URL-urile mele să arate ca /path/to/file/ în loc de /path/to/file.html , care este doar o preferință personală. De asemenea, am înființat două colecții: proiecte și oameni . Orice colecție nouă trebuie adăugată la fișierul de configurare.

Acum pot face foldere pentru aceste colecții în proiectul meu:

Numele folderelor trebuie să înceapă cu caracterul _ (subliniere), astfel încât Jekyll să știe ce să facă cu ele.

Realizarea unor obiecte

Primele obiecte pe care le vom face vor fi oamenii noștri. Vom folosi Markdown pentru a crea aceste fișiere, astfel încât să fie drăguțe și curate, dar totuși să genereze HTML adecvat, semantic. Puteți vedea că am făcut câteva fișiere pentru figuri din istoria Americii (acest lucru poate fi sau nu legat de faptul că ascult Hamilton non-stop de o lună acum):

Atributele pe care le vom pune în fișierul nostru pentru o persoană vor fi:

 --- object-id: first-name: last-name: job: listing-priority: wikipedia-url: ---

Vom folosi object-id pentru a ne referi în mod specific la oricare dintre aceste obiecte mai târziu. Vom împărți numele și prenumele, astfel încât să putem selecta ce combinație să folosim în diferite locuri (dacă sistemul dvs. solicită acest lucru) și vom folosi job pentru a defini ceea ce fac. (Evit „titlul” deoarece aceasta este deja o variabilă pe care paginile din Jekyll o au în mod implicit.) Am inclus și un atribut pentru prioritatea de listare care îmi va permite să sortez fiecare persoană după capriciu, dar puteți sorta și după unele metode încorporate, cum ar fi alfabetice sau numerice. În cele din urmă, avem un câmp pentru un link către pagina Wikipedia a persoanei respective.

Toate acestea sunt cuprinse între trei cratime în partea de sus și de jos pentru a-l defini ca YAML front-matter. Conținutul fiecărei biografii va merge după YAML și poate fi o cantitate și o structură arbitrară de HTML (dar vom folosi formatarea Markdown pentru a păstra totul frumos și curat).

Un obiect persoană complet populat arată astfel (conținutul este trunchiat pentru claritate):

 --- object-id: alexander-hamilton first-name: Alexander last-name: Hamilton job: 1st United States Secretary of the Treasury listing-priority: 1 wikipedia-url: https://en.wikipedia.org/wiki/Alexander_Hamilton --- Alexander Hamilton (January 11, 1755 or 1757 – July 12, 1804) was...

Și iată un obiect de proiect (conținutul este trunchiat pentru claritate):

 --- object-id: united-states-coast-guard title: United States Coast Guard featured: true featured-priority: 2 listing-priority: 1 architect-id: alexander-hamilton wikipedia-url: https://en.wikipedia.org/wiki/United_States_Coast_Guard --- The United States Coast Guard (USCG) is...

Acesta are câteva diferențe. Am setat un atribut featured . Dacă un proiect este prezentat, atunci acesta este listat pe pagina de pornire. Toate proiectele vor fi listate pe pagina de proiecte. Avem, de asemenea, setată ordinea noastră de sortare preferată pentru fiecare plasare. Și am inclus o referință la id -ul persoanei care a creat proiectul, astfel încât să ne putem referi direct la ea mai târziu.

Generarea de pagini din obiectele noastre

Modificând fișierul meu _config.yml , pot crea pagini pentru fiecare dintre aceste obiecte.

 permalink: pretty collections: projects: output: true people: output: true

Setarea output: true pentru fiecare colecție determină generarea unei pagini pentru fiecare obiect din interiorul acesteia. Dar pentru că obiectele noastre nu au conținut în fișierele lor, în prezent nu scot date, ceea ce înseamnă că vom primi doar pagini goale. Să construim un șablon de aspect pentru a face asta pentru noi.

Acest fișier va merge în folderul _layouts . Dar mai întâi, avem un fișier default.html acolo de care trebuie să ne ocupăm. Aceasta va păstra orice marcaj care este consecvent în toate fișierele noastre HTML.

 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title>{{ page.title }}</title> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="/css/styles.css" /> </head> <body> <header role="banner"> ... </header> <div role="main"> <div class="container"> {{ content }} </div> </div> <footer role="contentinfo"> ... </footer> </body> </html>

Veți observa o etichetă Liquid care arată astfel: {{ content }} . Fiecare fișier care este redat într-o pagină de către Jekyll are nevoie de un șablon specificat pentru el. După ce îi specificați șablonul, conținutul din acel fișier este redat în locația etichetei {{ content }} din șablonul de aspect. Acum nu trebuie să repetăm ​​lucrurile care vor fi pe fiecare pagină.

În continuare, vom construi un șablon unic de aspect pentru obiectele noastre persoane. Asta va arata asa:

 --- layout: default --- <header class="intro person-header"> <h1>{{ page.first-name }} {{ page.last-name }}</h1> <h2>{{ page.job }}</h2> </header> <div class="person-body"> {{ page.content }} <a href="{{ page.wikipedia-url }}">Read more about {{ page.first-name }} {{ page.last-name }} on Wikipedia</a> </div>

Acest fișier specifică faptul că codul său este inserat în șablonul de aspect implicit, iar apoi marcajul său este populat din datele din fișierele obiect de persoană.

Ultimul pas este să vă asigurați că fiecare obiect persoană specifică că folosește fișierul de aspect person.html . În mod normal, am insera asta în YAML din fișierele noastre de persoană, astfel:

 --- object-id: first-name: last-name: job: listing-priority: wikipedia-url: layout: person ---

Dar prefer să fac ca datele din fișierele mele obiect să conțină numai atribute relevante pentru modelul de conținut. Din fericire, îmi pot modifica fișierul _config.yml pentru a se ocupa de asta:

 exclude: - README.md permalink: pretty collections: projects: output: true people: output: true defaults: - scope: type: projects values: layout: project - scope: type: people values: layout: person

Acum, site-ul meu știe că orice obiect din colecția de proiecte ar trebui să folosească șablonul de aspect al proiectului, iar orice obiect din colecția de oameni ar trebui să folosească aspectul de persoană. Acest lucru mă ajută să-mi păstrez obiectele de conținut frumoase și curate.

Afișarea obiectelor pe o pagină de listă

Indiferent dacă alegem să scoatem pagini pentru obiectele noastre sau nu, le putem enumera și sorta după diferiți parametri. Iată cum am enumera toate proiectele noastre pe o pagină:

 --- layout: default title: Projects --- <header class="intro"> <h1>{{ page.title }}</h1> </header> <div class="case-studies-body"> <ul class="listing"> {% assign projects = site.projects | sort: 'listing-priority' %} {% for project in projects %} <li> <h2><a href="{{ project.url }}">{{ project.title }}</a></h2> {{ project.content }} </li> {% endfor %} </ul> </div>

Ceea ce am făcut este să creăm un <ul> pentru a ne pune lista înăuntru. Apoi, am creat o variabilă pe pagină numită projects și i-am atribuit toate obiectele proiectului nostru și le-am sortat după variabila listing-priority am creat-o în fiecare. În cele din urmă, pentru fiecare proiect din variabila noastră projects , scoatem un <li> care include date din atributele din fiecare fișier. Acest lucru ne oferă o listă extrem de controlabilă a obiectelor proiectului nostru, cu link-uri către paginile lor unice.

Pe pagina principală, în loc să afișăm toate proiectele, le vom afișa doar pe cele prezentate:

 <ul class="listing"> {% assign projects = site.projects | where: "featured", "true" | sort: 'featured-priority' %} {% for project in projects %} <li> <h3>{{ project.title }}</h3> <a href="{{ project.url }}">Learn about {{ project.title }}</a> </li> {% endfor %} </ul>

Orice obiect de proiect care are atributul featured setat la true va fi randat pe această pagină și va fi sortat după ordinea specială de prioritate pe care am stabilit-o pentru proiectele prezentate.

Acestea sunt exemple destul de simple despre cum să ieșim și să sortăm obiecte, dar ele demonstrează diferitele capacități pe care le putem crea pentru organizarea conținutului.

Conectarea la un obiect specific

Ultima caracteristică pe care o vom construi este conectarea la un anumit obiect. Acesta este ceva ce ați putea dori să faceți dacă legați un autor la o postare pe blog sau ceva similar. În cazul nostru, vom atașa o persoană la proiectul cu care sunt asociate în mod obișnuit. Dacă vă amintiți, obiectul nostru de proiect are un atribut architect-id , iar oamenii noștri au fiecare un atribut object-id . Putem atașa persoana corectă la un anumit proiect folosind aceste atribute.

Iată șablonul nostru de aspect al proiectului:

 --- layout: default --- {% assign architect = site.people | where: "object-id", page.architect-id | first %} <header class="intro project-header"> <h1>{{ page.title }}</h1> <p>Architected by: <a href="{{ architect.url }}">{{ architect.first-name }} {{ architect.last-name }}</a></p> </header> <div class="project-body"> {{ page.content }} <a href="{{ page.wikipedia-url }}">Read more about {{ page.title }} on Wikipedia</a> </div>

Linia 4 creează o variabilă numită architect și caută în toate obiectele oamenilor noștri orice cu un object-id care se potrivește cu atributul architect-id dintr-un proiect. Ar trebui să atribuim object-id astfel încât să fie returnat un singur rezultat, dar pentru a ne asigura că primim un singur răspuns și ne referim la el în loc de lista noastră de un articol, trebuie să setăm | first | first la sfârșitul etichetei noastre {% assign %} Liquid. Acest lucru ocolește o limitare a Jekyll, în care obiectele din colecții nu au ID-uri unice pentru început. Există o altă caracteristică numită date care permite ID-uri unice, dar nu scoate cu ușurință pagini și nu ne oferă posibilitatea de a ne sorta obiectele; lucrul în jurul limitărilor colecțiilor a fost o modalitate mai ușoară și mai curată de a obține funcționalitatea pe care o dorim.

Acum că pagina are un obiect unic care reprezintă arhitectul acelui proiect, putem numi atributele acestuia cu lucruri precum prenumele arhitectului și adresa URL a paginii Wikipedia. Voila! Conectare ușoară la obiecte prin ID unic.

Încheierea

Există câteva caracteristici suplimentare grozave care pot fi stabilite analizând documentele Jekyll mai detaliat, dar ceea ce avem aici sunt elementele de bază ale unui prototip bun de modelare a conținutului: capacitatea de a defini diferite tipuri de obiecte, atributele atașate acestor obiecte, și ID-uri care ne permit să apelăm anumite obiecte de oriunde. De asemenea, obținem o logică extrem de flexibilă pentru modelarea și afișarea obiectelor noastre în diferite locuri. Cel mai bun lucru este că întregul sistem este simplu și ușor de citit de către om și produce HTML simplu pentru a fi folosit în altă parte, dacă este necesar.

În scopuri de comunicare, avem acum un prototip care se poate face clic independent de platformă (un site web real) care va defini sistemul mai bine decât ar putea vreodată un PDF cu o grămadă de diagrame. Ne putem modifica modelul de conținut din mers pe măsură ce învățăm lucruri noi și trebuie să ne adaptăm. Putem introduce designerul și dezvoltatorul în sistem pentru a-și stabili modelele și arhitectura front-end, deoarece va accepta orice marcaj și CSS pe care doresc să le folosească. Putem chiar introduce editorii de conținut în el, configurându-i acces printr-o GUI GitHub sau o platformă de găzduire care permite utilizarea unui editor vizual precum Prose.io, GitHub Pages, CloudCannon sau Netlify.

Și nimic din toate acestea nu leagă o persoană de învățarea unor moduri de lucru specifice platformei, permițându-i să lucreze de la un nivel conceptual care se concentrează pe utilizatori și nu pe tehnologie.