Odpovědný design nejen vyzývá naše nástroje a přístupy k tvorbě a vývoji webových stránek, ale také nás nutí přezkoumat naše způsoby plánování a správy obsahu. Nové pracovní postupy vyžadují správné nástroje. Na první přemýšlení se otevírá příležitost pro zcela nové systémy správy obsahu (CMS) a vydavatelské platformy (a v blízké budoucnosti je pravděpodobně uvidíme spoustu). Ale každý, kdo někdy migroval z jednoho CMS do jiného, ví velmi dobře, že proces není bezbolestný. Takže můžeme přizpůsobit známé a populární CMS, jako je WordPress, které nám pomohou vytvářet a řídit adaptivní obsah?
Za prvé budeme muset věci urovnat. Co znamená adaptivní obsah a proč jej potřebujeme ve věku citlivého designu? Budeme také diskutovat o funkcích a nástrojích aplikace WordPress, které nám pomohou vytvořit platformu pro publikování přátelskou pro budoucnost. Snažíme se o dosažení vysokého cíle: mít obsah, který jakmile je vytvořen, může být flexibilně prezentován na různých zařízeních a v různých zobrazovacích podmínkách. Uvidíme, jak blízko se k tomu dostaneme.
Ve své nedávné knize Obsahová strategie pro mobilní zařízení , UX a specialista na obsahovou strategii Karen MacGrane poskytuje podrobné a dobře argumentované vysvětlení, proč potřebujeme nový přístup k správě obsahu. Jdeme nad rámec budování citlivých webů - vytváříme obsah, který může být publikován na různých platformách a dostupný na různých zařízeních. Co když zítra se chladnička stane primárním nástrojem pro spotřebování informací? Jsou vaše webové stránky připraveny k takovému použití?
Odpovědný design vznikl především z potřeby poskytnout mobilním uživatelům přiměřené zkušenosti. Upřímně však je "mobilní" jen část obrazu. Pokud se zamyslíme nad budoucností, můžeme snadno očekávat další nové platformy a zařízení, na kterých se bude zobrazovat náš obsah: hodinky, ledničky, brýle, mluvící roboty - vše, co si člověk dokáže představit. Znamená to, že potřebujeme vytvořit verzi "mluvícího robota" našich stránek? To by bylo šílenství. Takže, jaké řešení? Řešením je adaptivní obsah - obsah, který po vytvoření může být znovu použit v různých situacích a scénářích. Zní to skvěle, že? Jak to dosáhneme?
Náš obsah se již netýká "stránek". Jedná se o objekty, z nichž každý by měl být považován za soubor předdefinovaných prvků. Pro každou strukturální složku - kus - návrhový systém by odpovídal tomu, jak by měl být zobrazen ve všech scénářích. Kusy mohou být prezentovány v alternativních médiích nebo formátech pro různé případy použití. Například pokud máme video v našem obsahuovém objektu, můžeme mít popisný text nebo přepis pro scénáře, kde video nelze zobrazit. Nebo anotace pro objekt se mohou lišit podle scénáře - například když jsou sdíleny v sociálních médiích nebo zahrnuty ve výsledcích vyhledávání nebo zavedeny na webu.
Musíme udělat další krok k oddělení obsahu od prezentace. Ve skutečnosti je to důležitý princip redesignu a základní kámen webových standardů. Ale musíme jít dál a osvobodit se od mentality WYSIWYG. "Co vidíte" už není "to, co uživatelé vidí". To je nebezpečná iluze. Neměli bychom označovat náš text kurzídou nebo vkládat obrázky jako HTML do pole "obsah" stránky. "Měli bychom pouze zahrnout odkaz na obsahový objekt a nechat náš návrhový systém rozhodnout, jak prezentovat objekt.
Čím více práce odkládáme na programové nástroje (koneckonců chceme, aby byl náš obsah prezentován na různých platformách automaticky na základě předem definovaných scénářů, ne?), Tím více informací bychom měli těmto systémům poskytnout o obsahu. Například, v minulosti bychom mohli psát v obyčejné angličtině, že autor textu byl John Doe a označil jeho jméno odvážným - teď to nemůžeme. Potřebujeme samostatné pole v našem CMS, abychom zadali název a soubor pravidel, jak jej prezentovat v různých scénářích.
Potřebujeme jediný zdroj obsahu a publikační systém založený na scénářích, který se může rozhodnout, jak prezentovat požadovaný obsah uživateli podle svého prostředí (zařízení, rozlišení obrazovky, rychlost připojení atd.).
Mohou být všechny tyto aspekty dosaženy pomocí WordPress? Společnost MacGrane obviňuje WordPress a jiný blogovací software, protože nepodporuje vydavatele jako nástroj adaptivního obsahu. Konkrétně máme stále WYSIWYG editor ve WordPress s jednou textovou oblastí, do které vstupujeme do našeho "příspěvku". Bohužel se jedná o situaci, kterou čelí návrhář, který používal plošnou verzi programu WordPress. Naštěstí je WordPress trochu víc než jen "blogovací software". Stalo se tak vývojovou platformou, rámcem, pomocí kterého může vývojář poskytnout klientům skutečně moderní a budoucí zkušenosti.
Podívejme se, jaké nástroje máme jako vývojáři a jak je implementovat, abychom transformovali aplikaci WordPress na adaptivní publikační platformu pro naše klienty.
WordPress zahájil svůj pohyb směrem k plnohodnotnému CMS se zavedením vlastních typů příspěvků a vlastní taxonomie. Dalším silným prvkem, který lze použít v kombinaci s těmito funkcemi, jsou tzv. Vlastní pole. Toto jednoduché jméno odkazuje na grafické uživatelské rozhraní; ve skutečnosti tyto vlastní pole představují množinu metadat, která může být spojena s jakýmkoli objektem ve WordPressu. WordPress nám umožňuje vytvářet vysoce přizpůsobitelné uživatelské rozhraní pro metadata a flexibilní rozhraní API pro ukládání a přístup k nim.
Proč je to užitečné? U vlastních typů příspěvků již nejsme zablokováni do konceptu "stránky". Můžeme vytvořit typ příspěvku pro jakýkoli objekt, který potřebujeme (například zprávy, události, partnery - co se nám líbí) a strukturu objektu můžeme definovat prostřednictvím této sady metadat. Můžeme také vytvořit samostatné uživatelské rozhraní pro správu metadat. To vše dává našemu obsahu více struktury. Jakmile nám aplikace WordPress umožnila vytvářet metadata jakéhokoli typu, mohli bychom ji použít k ukládání alternativ pro vestavěné bloky obsahu, jako jsou názvy a popisy. (Mohli bychom například vidět SEO pluginy, které umožňují jedinečný SEO-cílový název a popis pro každý obsahový objekt.)
Jaké jsou jeho limity? WordPress je hodně kritizován za to, že neposkytuje důsledně API pro ukládání metadat. Konkrétně můžeme mít metadata pro příspěvky (a typy vlastních příspěvků) a pro uživatele, ale ne pro taxonomie (a plugin je potřeba pro to). Vytvoření uživatelského uživatelského rozhraní na obrazovce úprav pro příspěvek není tak snadné, jak by mohlo být. Předdefinované funkce a standardy chybí (což je důvod, proč různé pluginy dělají to jinak, což nás nechává s nepořádek, spíše než se systémem). Ale nedávné změny, které pomáhají sjednotit a optimalizovat ovládací panel WordPress, nám dávají naději.
Další skvělou vlastností aplikace WordPress je, že na jedné stránce umožňuje několik instancí editoru bohatých textů. To lze provést pomocí příkazu wp_editor , která nejen vytváří odpovídající značku textarea, ale také přidává funkci bohatých úprav a tlačítek pro výběr médií.
Proč je to užitečné? Pomocí této funkce můžeme zlomit jedno obsahové pole do několika podle struktury objektu. Přitom přidáváme strukturální složku k našim objektům. Také každá editovatelná oblast bude mít jednotné a známé GUI, které pomohou editoři snadno vložit potřebné značky do příslušných polí, včetně krátkých kódů.
Jaké jsou jeho limity? Měli bychom uchovávat data vložená do takových bohatě editovaných oblastí, jako jsou meta data, a to znamená více databázových volání atd. Takže tento přístup bude vyžadovat další pozornost k optimalizaci webu, jako je ukládání do mezipaměti. Neexistuje žádná vestavěná funkce, která by tyto údaje reprezentovala v šablonách, takže ji budeme muset vytvořit.
Tímto přístupem bude známá post-editační obrazovka zcela transformována:
Výše popsané nástroje WordPress nám umožňují lépe strukturovat náš obsah tím, že definujeme objekty a nahrazujeme jediný okraj obsahu se sadou polí, která ukládají různé části a meta data obsahu.
Nyní se podívejme, jaké nástroje máme k oddělení významu a prezentace. Ve skutečnosti existují jen dvě základní pravidla:
První pravidlo je snadné sledovat. Pomocí jednoduchého filtru můžeme odstranit vizuální editor pro všechny uživatele.
add_filter('user_can_richedit', '__return_false');
Druhé pravidlo je mnohem obtížnější sledovat. Samozřejmě, že v našem textu nebudeme hledat žádné HTML značky - ty, které představují opravdu sémantické prvky, jsou naprosto v pořádku. Ale když začneme vkládat Dalším obrovským problémem je způsob, jak WordPress vkládá do obsahových oblastí bohaté média - zejména obrázky -. V současné době vytiskne prostý kód HTML, který pevně zaktualizuje odkaz na obrázek, jeho velikost a značku obtékání. Je to nejhorší možný scénář adaptivního přístupu. Co když budeme potřebovat další variantu obrazu pro konkrétní případ použití? Co když jsme přesunuli knihovnu médií do jiné domény? Co kdybychom změnili konstrukci objektu a potřebujeme obrázek v jiné velikosti? Co když implementujeme odpověď, která vyžaduje, abychom specifikovali několik zdrojů pro jeden obrázek? Všechny tyto případy použití jsou naprosto nemožné, pokud neměníme implicitní chování aplikace WordPress. A přesto WordPress má skoro všechno, aby provedl posun k adaptivnímu přístupu: Celkově je možné označit značku pro média zkráceným kódem obsahujícím ID položky v knihovně médií. Velmi základní příklad by vypadal takto: uploads
samostatně, aby mohla být dynamická sestavení celé cesty. 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 = "