Adaptivt indhold med WordPress

Responsivt design udfordrer ikke kun vores værktøjer og tilgang til webdesign og udvikling, men tvinger også os til at gennemgå vores måder at planlægge og styre indhold på. Nye arbejdsgange kræver de rigtige værktøjer. Ved første tanker åbner dette mulighed for helt nye Content Management Systems (CMS) og publiceringsplatforme (og vi vil nok se mange af dem i den nærmeste fremtid). Men enhver, der nogensinde har migreret fra et CMS til en anden, ved godt, at processen ikke er smertefri. Så kan vi tilpasse et velkendt og populært CMS som WordPress til at hjælpe os med at oprette og administrere adaptivt indhold?

Først skal vi få ting lige. Hvad betyder adaptivt indhold, og hvorfor har vi brug for det i en aldrende responsiv design? Vi diskuterer også WordPress 'funktioner og værktøjer, som kan hjælpe os med at skabe en fremtidig venlig udgivelsesplatform. Vi sigter mod et højt mål: At have indhold, der, når de er oprettet, kan præsenteres fleksibelt på forskellige enheder og i forskellige synsforhold. Lad os se, hvor tæt vi kan komme til det.

Adaptivt indhold, og hvorfor vi har brug for det

I sin seneste bog Content Strategy for Mobile , UX og indholdsstrategisk specialist Karen MacGrane giver en detaljeret og velbegrundet forklaring på, hvorfor vi har brug for en ny tilgang til indholdshåndtering. Vi går videre end at opbygge lydhøre steder - vi skaber indhold, der kan udgives på forskellige platforme og få adgang til forskellige enheder. Hvad hvis i morgen et køleskab bliver en persons primære værktøj til forbrug af information? Er din hjemmeside klar til en sådan brugs sag?

Responsivt design er først og fremmest ud af behovet for at give mobile brugere en passende oplevelse. Ærligvis er "mobil" dog kun en del af billedet. Hvis vi tænker på fremtiden, kan vi let forvente andre nye platforme og enheder, som vores indhold vil vises på: ure, køleskabe, øjenbriller, snakkende robotter - alt man kan forestille sig. Betyder det, at vi skal oprette en "snakende robot" version af vores hjemmeside? Det ville være galskab. Så hvad er løsningen? Løsningen er adaptivt indhold - indhold, der, når de er oprettet, kan genbruges i forskellige situationer og scenarier. Det lyder godt, ikke? Hvordan opnår vi det?

1. Struktureret indhold

Vores indhold består ikke længere af "sider". Det består af objekter, der hver især skal betragtes som en pakke af foruddefinerede elementer. For hver konstruktionsdel - en del - vil designsystemet redegøre for, hvordan det skal vises i alle scenarier. Bunker kan præsenteres i alternative medier eller formater til forskellige brugssager. Hvis vi for eksempel har en video i vores indholdsobjekt, kunne vi have beskrivende tekst eller et transkript for scenarier, hvor videoen ikke kan ses. Eller annotationerne for et objekt kan variere alt efter scenariet - f.eks. Når de deles i sociale medier eller inkluderet i søgeresultater eller introduceres på et websted.

2. Præsentationsuafhængigt indhold

Vi skal tage det næste skridt hen imod at adskille indhold fra præsentationen. Faktisk er dette et vigtigt princip om redesign og en hjørnesten i webstandarder. Men vi må gå videre og befri os fra WYSIWYG mentaliteten. "Hvad du ser" er ikke "hvad dine brugere ser" længere. Det er en farlig illusion. Vi bør ikke markere vores tekst med kursiv eller indsætte billeder som HTML i feltet "indhold" på en "side". Vi skal bare inkludere en henvisning til et indholdsobjekt og lade vores design system bestemme, hvordan vi præsenterer objektet.

3. Metadata

Jo mere arbejde vi offload til programværktøjer (vi vil trods alt vores indhold præsenteres på forskellige platforme automatisk baseret på foruddefinerede scenarier, ikke?), Jo mere information skal vi give til disse systemer om indholdet. For eksempel kunne vi i fortiden skrive i ren engelsk, at forfatteren af en tekst var John Doe og mærke hans navn med fed skrift - nu kan vi ikke. Vi har brug for et særskilt felt i vores CMS for at indtaste navnet og et sæt regler for, hvordan vi præsenterer det i forskellige scenarier.

4. Genanvendeligt indhold

Vi har brug for en enkelt indholdskilde og et scenarieringsbaseret udgivelsessystem, der kan bestemme, hvordan man præsenterer det ønskede indhold til en bruger i henhold til deres omgivelser (enhed, skærmopløsning, forbindelseshastighed osv.).

Kan alle disse aspekter opnås med WordPress? MacGrane blames WordPress og anden blogging software til ikke at støtte udgivere som et redskab til adaptivt indhold. Specifikt har vi stadig en WYSIWYG-editor i WordPress, med et enkelt tekstområde for at komme ind i vores "indlæg." Desværre er det situationen for en designer, der bruger den almindelige out-of-the-box-version af WordPress. Heldigvis er WordPress lidt mere end bare "blogging software." Det er udviklet til en udviklingsplatform, en ramme, hvor en udvikler kan give kunderne en virkelig moderne og fremtidssikker oplevelse.

Transformere WordPress til en adaptiv publiceringsplatform

Lad os se, hvilke værktøjer vi har som udviklere, og hvordan de implementeres for at omdanne WordPress til en adaptiv publiceringsplatform til vores kunder.

WordPress startede sin bevægelse i retning af at være et fuldt udviklet CMS med indførelsen af brugerdefinerede posttyper og brugerdefinerede taxonomier. En anden stærk funktion, der skal bruges i kombination med disse, er de såkaldte brugerdefinerede felter. Dette enkle navn henviser til GUI; Faktisk repræsenterer disse brugerdefinerede felter sæt metadata, som kan knyttes til ethvert objekt i WordPress. WordPress giver os mulighed for at oprette et meget brugerdefineret brugergrænseflade til metadata og en fleksibel API til at gemme og få adgang til det.

Hvorfor er dette nyttigt? Med brugerdefinerede posttyper er vi ikke længere inde i "side" -konceptet. Vi kan skabe en posttype for ethvert objekt, vi har brug for (f.eks. Nyheder, arrangementer, partnere - uanset hvad vi kan lide), og vi kan definere objektets struktur gennem dette sæt metadata. Vi kan også oprette et separat brugergrænseflade til at administrere metadataene. Alt dette giver vores indhold mere struktur. Så snart WordPress tillod os at oprette metadata af enhver type, kunne vi bruge den til at gemme alternativer til indbyggede indholdsblokke som titler og beskrivelser. (For eksempel kan vi se SEO plugins, der giver mulighed for en unik SEO-målrettet titel og beskrivelse for hvert indholdsobjekt.)

Hvad er dens grænser? WordPress kritiseres meget for ikke konsekvent at levere en API til at gemme metadata. Specielt kan vi have metadata til indlæg (og brugerdefinerede indlægstyper) og brugere, men ikke for taxonomier (a plugin er nødvendig for det). Oprettelse af et brugerdefineret brugergrænseflade i redigeringsskærmen til et indlæg er ikke så nemt som det kunne være. Predefinerede funktioner og standarder mangler (det er derfor, forskellige plugins gør det anderledes og giver os et rod i stedet for et system). Men de seneste ændringer, der hjælper med at forene og optimere WordPress dashboard giver os håb.

En anden stor funktion af WordPress er, at det tillader flere forekomster af Rich Text Editor på en side. Dette kan implementeres med wp_editor funktion, der ikke kun skaber den tilsvarende tekstarea-markering, men tildeler også den rige redigeringsfunktionalitet til den og til medievalgsknapperne.

Hvorfor er dette nyttigt? Med denne funktion kan vi bryde et enkelt indholdsfelt i flere i henhold til en objekts struktur. Dermed tilføjer vi en strukturel komponent til vores objekter. Derudover vil hvert redigerbart område have en samlet og velkendt GUI, der kan hjælpe redaktører med at indsætte den nødvendige markering i de relevante felter, herunder kortnumre.

Hvad er dens grænser? Vi skal opbevare data, der er indtastet i sådanne rige redigeringsområder som metadata, og det betyder flere databasesamtaler mv. Derfor vil denne tilgang kræve yderligere opmærksomhed på optimering af webstedet, såsom caching. Der er ingen indbygget funktion til at repræsentere disse data i skabeloner, så vi skal oprette det.

Med denne tilgang ville den velkendte post-redigering skærm blive fuldstændig transformeret:

De ovenfor beskrevne WordPress-værktøjer gør det muligt for os at gøre vores indhold mere struktureret ved at definere objekter og erstatte en enkelt klump af indhold med et sæt felter, der gemmer indholdets forskellige dele og metadata.

Lad os nu se hvilke værktøjer vi skal adskille mening og præsentation. Faktisk er der kun to grundlæggende regler:

Slip af den visuelle editor.
Undgå at bruge almindeligt HTML i indholdsfelter så meget som muligt.

Den første regel er let at følge. Med et simpelt filter kan vi fjerne den visuelle editor for alle brugere.

add_filter('user_can_richedit', '__return_false');

Den anden regel er meget vanskeligere at følge. Vi vil bestemt ikke jage for hver HTML-tag i vores tekst - dem der repræsenterer virkelig semantiske elementer er helt OK. Men når vi begynder at indsætte

ind i et indholdsobjekt, kommer vi ind i problemer. Som vi ved, kan en kolonne i et scenario være noget helt anderledes i et andet.

Et andet stort problem skyldes den måde, WordPress indsætter rich media - især billeder - i indholdsfelter. I øjeblikket udskriver det almindeligt HTML, der hardcodes linket til billedet, dets størrelse og indpakning markup. Det er det værst mulige scenario for en adaptiv tilgang. Hvad hvis vi havde brug for en anden variant af et billede til en bestemt brugssag? Hvad hvis vi har flyttet vores mediebibliotek til et andet domæne? Hvad hvis vi har ændret design af et objekt og dermed har brug for billedet i en anden størrelse? Hvad hvis vi implementerer en lydhør teknik, der kræver, at vi angiver flere kilder til et billede? Alle disse brugssager er absolut umulige, hvis vi ikke ændrer WordPress 'standardadfærd.

Og alligevel har WordPress næsten alt for at gøre et skridt til en adaptiv tilgang mulig:

Hver medieobjekt i mediebiblioteket har sin egen post i databasen, der lagrer alle relevante oplysninger, herunder data om kildedata. Men WordPress lagrer ikke et absolut link til en fil; Det lagrer snarere filens navn og stien til uploads mappe separat, så den fulde sti kan bygges dynamisk.
WordPress har shortcode-funktionalitet, som giver dig mulighed for at referere til nogen markering inde i indholdsfelter og til at oprette den faktiske markering dynamisk, når indholdet udskrives i forenden.

Hvis vi sætter alt sammen, kan vi repræsentere markeringen for medier med en kortkode, der indeholder emnet for emnet i mediebiblioteket. Et meget grundlæggende eksempel ville se sådan ud:

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