Vastuullinen muotoilu ei ainoastaan ​​haastaa työkaluja ja lähestymistapoja web-suunnitteluun ja -kehitykseen, vaan myös pakottaa meidät tarkastelemaan sisältöömme suunnittelua ja hallintaa. Uudet työnkulut edellyttävät oikeita työkaluja. Ajatuksena on, että tämä avaa mahdollisuuden täysin uusiin sisällönhallintajärjestelmiin (CMS) ja julkaisualustoihin (ja näemme todennäköisesti paljon niitä lähitulevaisuudessa). Mutta kuka tahansa, joka on muuttanut jonkin CMS: stä toiseen, tietää hyvin, että prosessi ei ole kivuton. Voimmeko siis mukauttaa tuttua ja suosittua CMS: ää, kuten WordPressia, jotta voimme luoda ja hallita mukautuvia sisältöjä?

Ensinnäkin meidän on saatava asioita suoraan. Mitä mukautuva sisältö tarkoittaa, ja miksi sitä tarvitsemme reagoivan suunnittelun aikakaudella? Keskustelemme myös WordPressin ominaisuuksista ja työkaluista, jotka auttavat meitä luomaan tulevaisuuden ystävällisen julkaisutoiminnon. Tavoitteenamme on korkea tavoite: sisältö, joka luodaan kerran, voidaan esittää joustavasti eri laitteissa ja eri katseluolosuhteissa. Katsotaanpa, kuinka lähellä voimme päästä siihen.

Sopeutuva sisältö ja miksi sitä tarvitaan

Hänen viimeisimmässä kirjassaan Sisältöstrategia Mobileille , UX- ja sisältöstrategian asiantuntija Karen MacGrane antaa yksityiskohtaisen ja perustellun selityksen siitä, miksi tarvitsemme uutta lähestymistapaa sisällönhallintaan. Menemme pidemmälle kuin vastaavia sivustoja - luomme sisältöä, joka voidaan julkaista eri alustoilla ja käyttää eri laitteissa. Entä jos huomenna jääkaappi muuttuu jonkun ensisijaiseksi tiedonhankintavälineeksi? Onko sivustosi valmis tällaiseen käyttötapaukseen?

Reagoiva muotoilu on syntynyt enimmäkseen tarpeesta tarjota mobiilikäyttäjille riittävä kokemus. Rehellisesti kuitenkin "mobiili" on vain osa kuvaa. Jos ajattelemme tulevaisuutta, voimme helposti odottaa uusia uusia alustoja ja laitteita, joihin sisältömme ilmestyvät: kellot, jääkaapit, silmälasit, puhuvat robotit - mitä tahansa voi kuvitella. Tarkoittaako tämä, että meidän on luotava sivuston "puhuva robotti" -versio? Se olisi hulluutta. Joten, mikä ratkaisu on? Ratkaisu on mukautuva sisältö - sisältö, joka luodaan uudelleen, voidaan käyttää uudelleen erilaisissa tilanteissa ja skenaarioissa. Kuulostaa hyvältä, eikö niin? Miten saavutamme sen?

1. Strukturoitu sisältö

Sisältömme ei enää koostu "sivuista". Se koostuu esineistä, joista jokainen on pidettävä ennalta määriteltyjen elementtien pakettina. Jokaiselle rakenteelliselle komponentille - palo - suunnittelijärjestelmä huomioisi sen, miten se tulisi näyttää kaikissa skenaarioissa. Välilehdet voidaan esittää vaihtoehtoisissa välineissä tai formaateissa eri käyttötapauksissa. Jos esimerkiksi meillä on sisältöympäristöömme video, meillä voi olla kuvaava teksti tai transkripti skenaarioille, joissa videota ei voi katsella. Tai objektin merkinnät saattavat vaihdella skenaarion mukaan, esimerkiksi sosiaalisen median jakamisessa tai sisällyttäminen hakutuloksiin tai käyttöön sivustolla.

2. Esityksen itsenäinen sisältö

Meidän on tehtävä seuraava askel kohti sisällön erottamista esityksestä. Itse asiassa tämä on tärkeä uudistamisen periaate ja web-standardien kulmakivi. Mutta meidän on mentävä eteenpäin ja vapautettava itsemme WYSIWYG-mentaliteetista. "Mitä näet" ei enää ole "mitä käyttäjät näkevät". Se on vaarallinen illuusio. Meidän ei pitäisi merkitä tekstiä kursivoimalla tai lisätä kuvia HTML: n "sisältö" -kenttään. Sisällytä vain viittaus sisältöobjektiin ja anna suunnittelijärjestelmämme päättää esityksen esittelemisestä.

3. Metatiedot

Mitä enemmän töitä me ladataan ohjelmointivälineille (loppujen lopuksi haluamme, että sisältömme esitellään eri alustoilla automaattisesti ennalta määriteltyjen skenaarioiden perusteella), sitä enemmän tietoja, joita meidän on annettava näille järjestelmille sisällöstä. Esimerkiksi aiemmin voisimme kirjoittaa yksinkertaisella englanninkielellä, että tekijän tekijä on John Doe ja merkitse hänen nimensä lihavoituna - nyt emme voi. Tarvitsemme erillisen kentän CMS-palvelimemme sisältämään nimi ja säännöt siitä, miten se esitetään eri skenaarioissa.

4. Uudelleen käytettävissä oleva sisältö

Tarvitsemme vain yhden sisällön lähdekoodin ja skenaarioihin perustuvan julkaisutoiminnon, joka voi päättää, kuinka esittää pyydetty sisältö käyttäjälle niiden ympäristön (laitteen, näytön tarkkuuden, yhteyden nopeuden jne.) Mukaan.

Voivatko kaikki nämä näkökohdat saavuttaa WordPressin avulla? MacGrane syyttää WordPressiä ja muita bloggausohjelmistoja, jotka eivät tue julkaisijoita työkaluina mukautuvassa sisällössä. Erityisesti meillä on vielä WordPressissä WYSIWYG-editori, jossa on yksi tekstipuoli, johon päästään "viestiin". Valitettavasti tämä on tilanteessa, jossa suunnittelija käyttää WordPressin pelkkää out-of-the-box-versiota. Onneksi WordPress on muutakin kuin pelkkää "bloggausohjelmistoa". Se on kehittynyt kehittämisympäristöksi, kehykseksi, jonka avulla kehittäjä voi tarjota asiakkaille todella modernia ja tulevaa kokemusta.

WordPressin muuntaminen mukautuvaksi julkaisualustalle

Katsotaan, mitä työkaluja meillä on kehittäjinä ja miten heitä toteutetaan muuttaaksemme WordPressin mukautuvaksi julkaisualustaksi asiakkaillemme.

WordPress aloitti toimintansa kohti täysimittaista CMS-järjestelmää ottamalla käyttöön mukautettuja postityyppejä ja custom-taksonomia. Toinen tehokas ominaisuus, jota voidaan käyttää yhdessä näiden kanssa, ovat ns. Custom-kentät. Tämä yksinkertainen nimi viittaa graafiseen käyttöliittymään; itse asiassa nämä mukautetut kentät edustavat metatietoa, joka voidaan yhdistää minkä tahansa WordPress-objektin kanssa. WordPress antaa meille mahdollisuuden luoda hyvin muokattavissa oleva käyttöliittymä metatietoihin ja joustava API tallentaa ja käyttää sitä.

Miksi tämä on hyödyllistä? Muokattujen postityyppien kanssa emme ole enää lukeneet sivulle. Voimme luoda viestityypin mille tahansa tarvitsemallemme kohteelle (esimerkiksi uutiset, tapahtumat, kumppanit - mitä haluamme), ja voimme määrittää objektin rakenteen tällä metatietojen avulla. Voimme myös luoda erillisen käyttöliittymän metatietojen hallitsemiseksi. Kaikki tämä antaa sisällöllemme entistä enemmän rakennetta. Heti kun WordPress antoi meille mahdollisuuden luoda minkä tahansa tyyppisiä metatietoja, voisimme käyttää sitä tallentamaan vaihtoehtoja sisäänrakennetuille sisältölohkoille, kuten otsikoille ja kuvauksille. (Esimerkiksi näemme SEO-laajennuksia, jotka mahdollistavat ainutlaatuisen SEO-kohdennetun otsikon ja kuvauksen jokaiselle sisältöobjektille.)

Mitkä ovat sen rajat? WordPressä arvostellaan paljon, koska API ei ole jatkuvasti metatietojen tallentamista varten. Erityisesti meillä voi olla metatietoja viesteihin (ja mukautettuihin viesteihin) ja käyttäjiin, mutta ei taksonomiaan (a plugin tarvitaan sen vuoksi). Muokatun käyttöliittymän luominen muokkausnäyttöön ei ole niin helppoa kuin se voisi olla. Etukäteen määritellyt toiminnot ja standardit puuttuvat (siksi erilaiset laajennukset tekevät sen toisin, jättäen meille sotku eikä järjestelmä). Mutta viimeaikaiset muutokset, jotka auttavat yhdistämään ja optimoimaan WordPress-hallintapaneelin, antavat meille toivoa.

Toinen hieno ominaisuus WordPressissä on se, että se mahdollistaa useiden rikkaiden tekstieditorin esiintymät yhdellä sivulla. Tämä voidaan toteuttaa käyttämällä wp_editor toiminto, joka ei ainoastaan ​​luo vastaavaa tekstipohjaverkkoa, vaan myös antaa rikkaan muokkaustoiminnon sille ja mediavalintapainikkeille.

Miksi tämä on hyödyllistä? Tämän toiminnon avulla voimme katkaista yhden sisällön kentän useiksi objektin rakenteen mukaan. Tällöin lisätään rakenteellinen komponentti esineisiin. Jokaisella muokattavilla alueilla on myös yhtenäinen ja tuttu graafinen käyttöliittymä, joka auttaa toimittajia lisäämään tarvittavat merkinnät asianmukaisiin kenttiin, mukaan lukien lyhytkoodit.

Mitkä ovat sen rajat? Meidän pitäisi tallentaa tällaisiin rikkaisiin muokkausalueisiin syötetyt tiedot metatietoina, mikä tarkoittaa enemmän tietokannan puheluja jne. Joten tämä lähestymistapa edellyttää lisää huomiota sivuston optimointiin, kuten välimuistiin. Näitä tietoja ei ole sisäänrakennetulla toiminnolla mallineissa, joten meidän on luotava ne.

Tämän lähestymistavan avulla tuttu postinmuokkausnäyttö muuttuisi täysin:

Yllä käsitellyt WordPress-työkalut mahdollistavat sisällöllisempi sisällön määrittelemällä kohteet ja korvaamalla yhden sisällön palan useilla kentillä, jotka tallentavat sisällön eri osia ja metatietoja.

Katsotaan nyt, mitä työkaluja meidän on erotettava merkitys ja esitys. Itse asiassa on vain kaksi perussääntöä:

  1. Vapauta visuaalinen editori.
  2. Vältä HTML-koodien käyttöä sisältökentissä mahdollisimman paljon.

Ensimmäistä sääntöä on helppo noudattaa. Yksinkertaisella suodattimella voimme poistaa visuaalisen editoijan kaikille käyttäjille.

add_filter('user_can_richedit', '__return_false');

Toinen sääntö on paljon vaikeampi noudattaa. Tietenkään emme aio metsästää tekstiä jokaiselle HTML-tunnisteelle - ne, jotka edustavat todella semanttisia elementtejä, ovat ehdottomasti OK. Mutta kun aloitamme lisäyksen

osaksi sisältöobjektia, saamme ongelmia. Kuten tiedämme, sarakkeessa yhdessä skenaariossa saattaa olla jotain aivan toista eräässä toisessa.

Toinen valtava ongelma syntyy siitä, miten WordPress lisää rikas media - etenkin kuvat - sisältökenttiin. Tällä hetkellä se tulostaa selkeän HTML-koodin, joka koodaa linkin kuvan, sen koon ja käärintämerkinnän suhteen. Se on pahin mahdollinen skenaario mukautuvaan lähestymistapaan. Entä jos tarvitsisimme toisen kuvan vaihtoehdon tietylle käytölle? Entä jos olemme siirtäneet mediakirjastomme toiseen verkkotunnukseen? Entä jos olemme muuttaneet objektin muotoa ja tarvitsemmekkää sitten kuvaa toisessa koossa? Mitä jos toteutamme herkkiä tekniikoita, jotka edellyttävät meiltä useita lähteitä yhdelle kuvalle? Kaikki nämä käyttötapaukset ovat täysin mahdottomia, jos emme muuta WordPressin oletuskäyttäytymistä.

WordPressillä on kuitenkin lähes kaikki mahdollisuudet siirtyä mukautuvaan lähestymistapaan:

  • Mediakirjaston jokaisella mediasisältöllä on oma tietokannassa oleva merkintä, joka tallentaa kaikki olennaiset tiedot, mukaan lukien lähdetiedoston tiedot. Mutta WordPress ei tallenna absoluuttista linkkiä tiedostoon; pikemminkin se tallentaa tiedoston nimen ja polun uploads kansioon erikseen, jotta koko polku voidaan rakentaa dynaamisesti.
  • WordPressillä on lyhytkooditoiminto, jonka avulla voit viitata minkä tahansa merkinnän sisältökenttiin ja luoda todellisen merkinnän dynaamisesti, kun sisältö tulostetaan etupäässä.

Kun kaikki yhdistetään, voimme edustaa mediakoodeja, joissa on lyhytkoodi, joka sisältää kohteen tunnuksen mediakirjastossa. Erittäin perusläheinen esimerkki näyttäisi tästä:

add_shortcode('frl_image', 'frl_image_screen');function frl_image_screen($atts, $content = ''){extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));$out = '';$id = intval($id);if($id == 0)return ''; // no attachment$out = "