Adaptivt innehåll med WordPress

Responsiv design utmanar inte bara våra verktyg och metoder för webbdesign och utveckling, men tvingar oss också att granska våra sätt att planera och hantera innehåll. Nya arbetsflöden kräver rätt verktyg. Vid första tanke öppnar detta ett tillfälle för helt nya system för innehållshantering (CMS) och publiceringsplattformar (och vi kommer nog att se massor av dem inom en snar framtid). Men den som någonsin migrerat från ett CMS till en annan vet väldigt bra att processen inte är smärtfri. Så kan vi anpassa ett välbekant och populärt CMS som WordPress för att hjälpa oss att skapa och hantera anpassat innehåll?

Först måste vi få saker rakt. Vad betyder adaptivt innehåll, och varför behöver vi det i en tid med responsiv design? Vi diskuterar också WordPress 'funktioner och verktyg som kan hjälpa oss att skapa en framtida vänlig publiceringsplattform. Vi strävar efter ett högt mål: Att ha innehåll som, en gång skapat, kan presenteras flexibelt på olika enheter och i olika läsförhållanden. Låt oss se hur nära vi kan komma till det.

Adaptivt innehåll, och varför behöver vi det

I hennes senaste bok Content Strategy for Mobile , UX och content strategy specialist Karen MacGrane ger en detaljerad och välförklarad förklaring till varför vi behöver ett nytt tillvägagångssätt för innehållshantering. Vi går vidare än att bygga upp svåra platser - vi skapar innehåll som kan publiceras på olika plattformar och åtkomst till olika enheter. Vad händer om imorgon ett kylskåp blir någons främsta verktyg för att konsumera information? Är din webbplats redo för ett sådant användarfall?

Responsiv design har uppstått för det mesta av behovet av att ge mobila användare en adekvat upplevelse. Ärligt talat är "mobil" dock bara en del av bilden. Om vi ​​tänker på framtiden kan vi enkelt förvänta oss andra nya plattformar och enheter som vårt innehåll kommer att visas på: klockor, kylskåp, ögonglasögon, pratande robotar - allt man kan tänka sig. Betyder det att vi behöver skapa en "talk robot" -version av vår webbplats? Det skulle vara galenskap. Så, vad är lösningen? Lösningen är adaptivt innehåll - innehåll som, när det är skapat, kan återanvändas i olika situationer och scenarier. Det låter bra, eller hur? Hur uppnår vi det?

1. Strukturerad innehåll

Vårt innehåll består inte längre av "sidor". Det består av föremål, vilka var och en ska betraktas som ett paket av fördefinierade element. För varje strukturell komponent - en bit - skulle designsystemet redogöra för hur det ska visas i alla scenarier. Bunkar kan presenteras i alternativa media eller format för olika användningsfall. Om vi ​​till exempel har en video i vårt innehållsobjekt kan vi ha beskrivande text eller ett transkript för scenarier där videon inte kan visas. Eller annoteringarna för ett objekt kan variera beroende på scenariot, t.ex. när de delas i sociala medier eller ingår i sökresultat eller presenteras på en webbplats.

2. Presentation oberoende innehåll

Vi måste ta nästa steg mot att skilja innehållet från presentationen. Egentligen är detta en viktig princip för omkonstruktion och en hörnsten av webbstandarder. Men vi måste gå vidare och befria oss från WYSIWYG-mentaliteten. "Vad du ser" är inte "vad dina användare ser" längre. Det är en farlig illusion. Vi bör inte markera vår text med kursiv eller infoga bilder som HTML i fältet "innehåll" på en "sida". Vi borde bara inkludera en referens till ett innehållsobjekt och låta vårt designsystem bestämma hur man presenterar objektet.

3. Metadata

Ju mer arbete vi laddar ner till programverktyg (trots allt vill vi att innehållet presenteras på olika plattformar automatiskt baserat på fördefinierade scenarier, eller hur?), Desto mer information ska vi ge till systemen om innehållet. Till exempel kunde vi i det förflutna skriva på vanlig engelska att författaren av en text var John Doe och markera hans namn i fetstil - nu kan vi inte. Vi behöver ett separat fält i vårt CMS för att ange namnet och en uppsättning regler för hur vi presenterar det i olika scenarier.

4. Återanvändbart innehåll

Vi behöver en enda innehållskälla och ett scenariobaserat publiceringssystem som kan bestämma hur man ska presentera det begärda innehållet för en användare enligt deras miljö (enhet, skärmupplösning, anslutningshastighet etc.).

Kan alla dessa aspekter uppnås med WordPress? MacGrane skyller WordPress och annan bloggprogramvara för att inte stödja utgivare som ett verktyg för adaptivt innehåll. Specifikt har vi fortfarande en WYSIWYG-editor i WordPress, med ett enda textområde för att komma in i vårt "inlägg". Tyvärr är det här läget för en designer som använder den vanliga versionen av WordPress. Lyckligtvis är WordPress lite mer än bara "bloggar". Det har utvecklats till en utvecklingsplattform, en ram som en utvecklare kan erbjuda kunderna en verkligt modern och framtidsbeständig upplevelse.

Transformera WordPress till en adaptiv publiceringsplattform

Låt oss se vilka verktyg vi har som utvecklare, och hur man implementerar dem för att omvandla WordPress till en adaptiv publiceringsplattform för våra kunder.

WordPress började sin rörelse mot att vara ett fullvärdigt CMS med införandet av anpassade posttyper och anpassade taxonomier. En annan kraftfull funktion som ska användas i kombination med dessa är de så kallade anpassade fälten. Detta enkla namn hänvisar till GUI; I själva verket representerar dessa anpassade fält uppsättningen metadata som kan kopplas till något objekt i WordPress. WordPress ger oss möjlighet att skapa ett mycket anpassningsbart användargränssnitt för metadata och ett flexibelt API för att lagra och komma åt det.

Varför är det här till hjälp? Med anpassade posttyper låses vi inte längre till "sidan" -konceptet. Vi kan skapa en posttyp för alla objekt vi behöver (t.ex. nyheter, händelser, partners - vad vi än vill), och vi kan definiera objektets struktur genom denna uppsättning metadata. Vi kan också skapa ett separat användargränssnitt för att hantera metadata. Allt detta ger vårt innehåll mer struktur. Så snart som WordPress tillät oss att skapa metadata av någon typ, kan vi använda den för att lagra alternativ för inbyggda innehållsblock som titlar och beskrivningar. (Till exempel kan vi se SEO plugins som möjliggör en unik SEO-riktad titel och beskrivning för varje innehållsobjekt.)

Vad är dess gränser? WordPress kritiseras mycket för att inte konsekvent tillhandahålla ett API för att lagra metadata. Specifikt kan vi ha metadata för inlägg (och anpassade inläggstyper) och användare, men inte för taxonomier (a plugin behövs för det). Att skapa ett anpassat användargränssnitt i redigeringsskärmen för ett inlägg är inte lika enkelt som det kan vara. Fördefinierade funktioner och standarder saknas (det är därför olika plugins gör det annorlunda, vilket ger oss en röra snarare än ett system). Men senaste förändringar som hjälper till att förena och optimera WordPress-instrumentbrädan ger oss hopp.

En annan stor egenskap av WordPress är att det tillåter flera instanser av Rich Text Editor på en sida. Detta kan implementeras med wp_editor funktion, som inte bara skapar motsvarande textarea-markering, men tilldelar också den rika redigeringsfunktionen till den och med mediavalsknapparna.

Varför är det här till hjälp? Med den här funktionen kan vi bryta ett enda innehållsfält i flera enligt ett objekts struktur. Därmed lägger vi till en strukturell komponent i våra föremål. Dessutom kommer varje redigerbart område att ha en enhetlig och välbekant GUI som hjälper redaktörer att enkelt infoga den nödvändiga markeringen i lämpliga fält, inklusive kortnummer.

Vad är dess gränser? Vi borde lagra data som är inskrivna i sådana rika redigeringsområden som metadata, och det betyder fler databasuppkopplingar etc. Således kommer detta tillvägagångssätt att kräva ytterligare uppmärksamhet åt optimering av webbplatsen, såsom caching. Det finns ingen inbyggd funktion för att representera denna data i mallar, så vi måste skapa den.

Med detta tillvägagångssätt skulle den välbekanta efterredigeringsskärmen helt omvandlas:

De ovan beskrivna WordPress-verktygen gör det möjligt för oss att göra vårt innehåll mer strukturerat genom att definiera objekt och ersätta en enda grupp innehåll med en uppsättning fält som lagrar innehållets olika delar och metadata.

Låt oss nu se vilka verktyg vi måste skilja menings och presentation. Det finns faktiskt bara två grundläggande regler:

1. Bli av med bildredigeraren.
2. Undvik att använda vanlig HTML i innehållsfält så mycket som möjligt.

Den första regeln är lätt att följa. Med ett enkelt filter kan vi ta bort den visuella redigeraren för alla användare.

add_filter('user_can_richedit', '__return_false');

Den andra regeln är mycket svårare att följa. Visst, vi ska inte jaga efter varje HTML-tagg i vår text - de som representerar verkligen semantiska element är helt OK. Men när vi börjar infoga

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 = "