Responsiv design utfordrer ikke bare våre verktøy og tilnærminger til webdesign og utvikling, men tvinger oss også til å gjennomgå våre måter å planlegge og administrere innhold på. Nye arbeidsflyter krever de riktige verktøyene. Ved første tanke åpner dette en mulighet for helt nye innholdsstyringssystemer (CMS) og publiseringsplattformer (og vi vil nok se mange av dem i nær fremtid). Men alle som noen gang har migrert fra en CMS til en annen, vet veldig godt at prosessen ikke er smertefri. Så kan vi tilpasse et kjent og populært CMS som WordPress for å hjelpe oss med å skape og administrere adaptivt innhold?

Først må vi få ting rett. Hva betyr adaptivt innhold, og hvorfor trenger vi det i en aldrende responsiv design? Vi vil også diskutere WordPress 'funksjoner og verktøy som kan hjelpe oss med å skape en fremtidssikker publiseringsplattform. Vi satser på et høyt mål: å ha innhold som, når de er opprettet, kan presenteres fleksibelt på forskjellige enheter og i forskjellige visningsforhold. La oss se hvor nær vi kan komme til det.

Adaptivt innhold, og hvorfor vi trenger det

I hennes siste bok Innholdsstrategi for mobil , UX og innholdsstrategispesialist Karen MacGrane gir en detaljert og velbegrunnet forklaring på hvorfor vi trenger en ny tilnærming til innholdshåndtering. Vi går videre enn å bygge responsive nettsteder - vi lager innhold som kan publiseres på ulike plattformer og åpnes på ulike enheter. Hva om i morgen et kjøleskap blir noens primære verktøy for å konsumere informasjon? Er nettstedet ditt klart for en slik brukstilfelle?

Responsiv design har oppstått for det meste ut av behovet for å gi mobilbrukere en tilstrekkelig opplevelse. Ærlig, men "mobil" er bare en del av bildet. Hvis vi tenker på fremtiden, kan vi lett forvente andre nye plattformer og enheter som innholdet vårt vil se ut: klokker, kjøleskap, briller, snakkende roboter - alt man kan forestille seg. Betyr dette at vi trenger å lage en "snakkende robot" -versjon av nettstedet vårt? Det ville være galskap. Så, hva er løsningen? Løsningen er adaptivt innhold - innhold som, når det er opprettet, kan gjenbrukes i forskjellige situasjoner og scenarier. Høres bra ut, ikke sant? Hvordan oppnår vi det?

1. Strukturert innhold

Innholdet består ikke lenger av "sider". Det består av objekter, som hver skal betraktes som en pakke med forhåndsdefinerte elementer. For hver strukturell komponent - en bit - vil designsystemet regne med hvordan det skal vises i alle scenarier. Biter kan bli presentert i alternative medier eller formater for forskjellige brukstilfeller. Hvis vi for eksempel har en video i innholdsobjektet, kan vi ha beskrivende tekst eller et transkripsjon for scenarier der videoen ikke kan vises. Eller annotasjonene for et objekt kan variere i henhold til scenariet - som for eksempel når de deles i sosiale medier, eller inkluderes i søkeresultatene, eller introduseres på et nettsted.

2. Presentasjonsuavhengig innhold

Vi må ta neste skritt mot å skille innhold fra presentasjonen. Egentlig er dette et viktig prinsipp for redesign og en hjørnestein i webstandarder. Men vi må gå videre og befri oss fra WYSIWYG mentaliteten. "Det du ser" er ikke "hva brukerne dine ser" lenger. Det er en farlig illusjon. Vi bør ikke merke vår tekst med kursiv eller sette inn bilder som HTML i «innhold» -feltet på en «side». Vi bør bare inkludere en referanse til et innholdsobjekt og la designsystemet bestemme hvordan vi skal presentere objektet.

3. Metadata

Jo mer arbeid vi laster ned for å programmere verktøy (tross alt, vi vil at innholdet vårt skal presenteres på ulike plattformer automatisk basert på forhåndsdefinerte scenarier, ikke sant?), Jo mer informasjon bør vi gi til systemene om innholdet. For eksempel kunne vi i det siste skrive på vanlig engelsk at forfatteren av en tekst var John Doe og merke navnet hans i fet skrift - nå kan vi ikke. Vi trenger et eget felt i vårt CMS for å skrive inn navnet og et sett med regler for hvordan å presentere det i forskjellige scenarier.

4. Gjenbrukbart innhold

Vi trenger en enkelt innholdskilde og et scenariobasert publiseringssystem som kan bestemme hvordan vi skal presentere det forespurte innholdet til en bruker i henhold til deres miljø (enhet, skjermoppløsning, tilkoblingshastighet, etc.).

Kan alle disse aspektene oppnås med WordPress? MacGrane blames WordPress og annen blogging programvare for ikke å støtte utgivere som et verktøy for adaptivt innhold. Spesielt har vi fortsatt en WYSIWYG-editor i WordPress, med et enkelt tekstområde for å legge inn vårt "innlegg". Dessverre er dette situasjonen som står over for en designer ved hjelp av den enkle, utrykte versjonen av WordPress. Heldigvis er WordPress litt mer enn bare "blogging software." Den har utviklet seg til en utviklingsplattform, et rammeverk som en utvikler kan gi kundene en virkelig moderne og fremtidssikker opplevelse.

Transformere WordPress til en adaptiv publiseringsplattform

La oss se hvilke verktøy vi har som utviklere, og hvordan implementere dem for å transformere WordPress til en adaptiv publiseringsplattform for våre kunder.

WordPress startet sin bevegelse mot å være et fullverdig CMS med innføring av egendefinerte innleggstyper og egendefinerte taksonomier. En annen kraftig funksjon som skal brukes i kombinasjon med disse er de såkalte tilpassede feltene. Dette enkle navnet refererer til GUI; Faktisk representerer disse egendefinerte feltene metadataene som kan knyttes til ethvert objekt i WordPress. WordPress gir oss muligheten til å lage et svært tilpassbart brukergrensesnitt for metadata og en fleksibel API for å lagre og få tilgang til den.

Hvorfor er dette nyttig? Med tilpassede posttyper, er vi ikke låst inn i «side» -konseptet lenger. Vi kan lage en posttype for ethvert objekt vi trenger (for eksempel nyheter, hendelser, partnere - uansett hva vi liker), og vi kan definere objektets struktur gjennom dette settet metadata. Vi kan også opprette et eget brukergrensesnitt for å administrere metadataene. Alt dette gir innholdet mer struktur. Så snart WordPress tillot oss å lage metadata av noe slag, kan vi bruke den til å lagre alternativer for innebygde innholdsblokker som titler og beskrivelser. (For eksempel kan vi se SEO-plugins som tillater en unik SEO-målrettet tittel og beskrivelse for hvert innholdsobjekt.)

Hva er grensene sine? WordPress kritiseres mye for ikke å gi en API for å lagre metadata konsekvent. Spesielt kan vi ha metadata for innlegg (og tilpassede innleggstyper) og brukere, men ikke for taksonomier (a plugin er nødvendig for det). Å lage et tilpasset brukergrensesnitt i redigeringsskjermen for et innlegg er ikke så enkelt som det kunne være. Forhåndsdefinerte funksjoner og standarder mangler (det er derfor forskjellige plugins gjør det annerledes, og gir oss et rot, i stedet for et system). Men de siste endringene som bidrar til å forene og optimalisere WordPress-dashbordet gir oss håp.

En annen flott funksjon av WordPress er at det tillater flere forekomster av den rike teksteditoren på en side. Dette kan implementeres med wp_editor funksjon, som ikke bare skaper tilsvarende tekstarea-markering, men tildeler også rikredigeringsfunksjonalitet til den og til mediavalgknappene.

Hvorfor er dette nyttig? Med denne funksjonen kan vi bryte et enkelt innholdsfelt i flere i henhold til en objekts struktur. Dermed legger vi til en strukturell komponent i objektene våre. Også hvert redigerbart område vil ha en enhetlig og kjent GUI som vil hjelpe redaktører enkelt å sette inn nødvendig merking i de aktuelle feltene, inkludert kortnummer.

Hva er grensene sine? Vi bør lagre data som er inngått i slike rike redigeringsområder som metadata, og det betyr flere databasesamtaler osv. Så denne tilnærmingen vil kreve ytterligere oppmerksomhet på optimalisering av nettstedet, for eksempel caching. Det er ingen innebygd funksjon for å representere disse dataene i maler, så vi må opprette den.

Med denne tilnærmingen ville det velkjente etterredigeringsskjermbildet bli fullstendig omdannet:

WordPress-verktøyene som er omtalt ovenfor, gjør oss i stand til å gjøre innholdet mer strukturert ved å definere objekter og erstatte en enkelt blokk med innhold med et sett med felt som lagrer innholdets ulike deler og metadata.

La oss nå se hvilke verktøy vi må skille mellom mening og presentasjon. Egentlig er det bare to grunnleggende regler:

  1. Bli kvitt den visuelle redaktøren.
  2. Unngå å bruke vanlig HTML i innholdsfelt så mye som mulig.

Den første regelen er lett å følge. Med et enkelt filter kan vi fjerne visuelt redigeringsverktøy for alle brukere.

add_filter('user_can_richedit', '__return_false');

Den andre regelen er mye vanskeligere å følge. Sikkert, vi skal ikke jakte på alle HTML-merkene i teksten vår - de som representerer virkelig semantiske elementer, er helt OK. Men når vi begynner å sette inn

inn i et innholdsobjekt, kommer vi inn i problemer. Som vi vet, kan en kolonne i ett scenario være noe helt annerledes i et annet.

Et annet stort problem skyldes hvordan WordPress legger inn rike medier - spesielt bilder - i innholdsfelt. For øyeblikket skriver det ut vanlig HTML som hardcodes linken til bildet, størrelsen og innpakningen. Det er det verste mulige scenariet for en adaptiv tilnærming. Hva om vi trengte en annen variant av et bilde for et bestemt brukstilfelle? Hva om vi har flyttet vårt mediebibliotek til et annet domene? Hva om vi har endret design av et objekt og dermed trenger bildet i en annen størrelse? Hva om vi implementerer en lydhør teknikk som krever at vi angir flere kilder for ett bilde? Alle disse tilfellene er absolutt umulige hvis vi ikke endrer WordPress 'standardadferd.

Og likevel har WordPress nesten alt for å gjøre et trekk til en adaptiv tilnærming mulig:

  • Hvert medieelement i mediebiblioteket har sin egen oppføring i databasen som lagrer all relevant informasjon, inkludert data om kildefilen. Men WordPress lagrer ikke en absolutt lenke til en fil; heller lagrer den filens navn og banen til uploads mappe separat, slik at hele banen kan bygges dynamisk.
  • WordPress har shortcode-funksjonalitet som gir deg mulighet til å referere til eventuelle markeringer i innholdsfeltene og for å opprette den faktiske merkingen dynamisk når innholdet skrives ut i forkant.

Når vi setter alt sammen, kan vi representere oppslaget for media med en kortkode som inneholder IDen til elementet i mediebiblioteket. Et veldig grunnleggende eksempel vil se slik ut:

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