En komplett guide til progressiv forbedring
I årevis har webdesignere brukt grasiøse nedbrytningsprinsipper for å sikre at besøkende i eldre nettlesere i det minste kan se innholdet på sine nettsteder, selv om de ikke ser nøyaktig hvordan designeren har tenkt.
Grasiøs nedbrytning lar designere designe for de nyeste og beste nettleserne uten å fullstendig fremmedgjøre de som bruker eldre nettleserversjoner.
Og bare fordi de med eldre nettlesere ofte har en mindre brukervennlig brukeropplevelse, har ikke avskrekket designere fra å plassere sitt fokus helt på de nyeste teknologiene og teknikkene, og rasjonaliserer at de som bruker eldre nettlesere, enten var vant til det eller bare skal oppgradere.
Progressiv forbedring gir oss et bedre alternativ. I stedet for å fokusere på nettleserteknologi og støtte, fokuserer PE på innhold.
Som de fleste designere helt sikkert vil være enige om, er innhold den viktigste delen av nesten alle websider. Men mange designere forstår ikke fullt ut progressiv forbedring, hvordan det fungerer, og hvorfor det er en bedre modell enn grasiøs nedbrytning.
Les videre for svar på disse spørsmålene og informasjon om hvordan du bruker progressiv forbedring på ditt neste webdesignprosjekt.
Hvem drar nytte av Progressive Enhancement?
Mange designere tror progressiv forbedring bare fordeler de brukerne som bruker utdaterte nettlesere, men andre brukere nyter også. Mobilbrowsere er mest sannsynlig å dra full nytte av progressiv forbedring. Årsakene til dette er to ganger. For det første kan mobile nettlesere som ikke støtter CSS eller JavaScript, fortsatt vise innholdet på nettstedet ditt. Mens de fleste moderne smarte telefonbrowsere støtter minst en av disse, gjør ikke alle nettlesere for grunnleggende mobiltelefoner.
Den andre måten de mobile nettleserne har, er at nettsteder som er bygget med progressiv forbedring, lettere kan innlemme en mobilversjon. Tross alt vil grunnlaget HTML fungere uansett CSS lagdelt på toppen av det. Så å lage et eget stilark for mobile nettlesere krever ikke mye ekstra arbeid.
Skjermlesere har også en mye enklere tid hvis basen HTML er godt strukturert og semantisk. Dette gjør nettstedet ditt mye mer tilgjengelig for de som bruker skjermlesere. Søkemotorer kan lettere skanne velformatert HTML enn dårlig kodede sider, noe som kan bety mye bedre søkemotorplassering for nettstedet ditt.
Andre fordeler med progressiv forbedring
Utover de umiddelbare fordelene med forbedret brukeropplevelse, er nettsteder som er bygget med progressiv forbedring, generelt lettere å vedlikeholde enn andre nettsteder.
Fordi det grunnleggende innholdet og funksjonaliteten holdes helt skilt fra de visuelle elementene på siden, bør endringer i utseendet til nettstedet ikke engang påvirke måten nettstedet fungerer eller innholdet det inneholder. Re-tema på nettstedet ditt er det mye lettere på grunn av dette. Alt du trenger å gjøre er å endre CSS-filene dine.
Og ærlig talt bør vi ikke overse fordelene ved et nettsted som kan ses i det største antallet nettlesere der ute.
Selv om ikke alle vil få en identisk opplevelse, kan det være at noen som bruker en utdatert eller foreldet nettleser, fortsatt kan se innholdet på nettstedet ditt, kan føre til flere besøkende eller kunder. Nettsteder som tar en tilnærming som starter med progressiv forbedring, trenger ikke å gjøre noe ekstra arbeid for å gjøre dette mulig.
Bygg fra innsiden ut
Progressiv forbedring fokuserer ikke på nettleserkompatibilitet på samme måte som grasiøs nedbrytning gjør det. I stedet fokuserer den først på innholdet, deretter ved presentasjon av det innholdet, og deretter på noen skripting. På denne måten, uansett hvilken enhet eller nettleser en besøkende bruker, kan de se innholdet ditt uten problemer.
Progressiv forbedring kan også ha fordeler for tilgjengelighet og til og med søkemotoroptimalisering. Ved å starte med velstrukturert, semantisk HTML, gir du et godt grunnlag for å bygge opp utformingen av nettstedet ditt. Og denne grunnleggende HTML er lett å tolke av skjermlesere og søkemotor edderkopper.
Sett inn innhold først
Når du starter et nytt nettstedsprosjekt, bør du først konsentrere deg om innholdsstrukturen. Ved å skape velstrukturert, semantisk HTML som grunnlag for nettstedet ditt, har du en lettere tid med presentasjonsnivået til designet.
God gjennomtenkt HTML har fordelen av at du ikke trenger presentasjonslag for å gi mening. Det betyr at skjermlesere, søkemotor edderkopper, og de på grunnleggende mobile nettlesere vil kunne se innholdet ditt uten forstyrrende formateringsproblemer.
Du kan se ovenfor, hvordan MSNBC beholder alt innholdet i omtrent samme rekkefølge selv uten CSS. Siden er perfekt brukbar selv uten presentasjonslaget.
Selv om strukturen til et nettsted vil være avhengig av innholdet på det aktuelle nettstedet, er det noen retningslinjer du bør bruke for grunnleggende nettsteder.
Start med overskriften, deretter hovednavigasjonen, etterfulgt av innhold. Etter innholdet ditt, vil du legge til ytterligere sidefeltinformasjon eller linker, og deretter informasjonen om bunnteksten.
På denne måten vises identifikasjonsinformasjonen for nettstedet ditt først, etterfulgt av navigasjon (hvis noen ønsker å gå direkte til en annen side, som din kontakt eller om siden), og så kommer det rett inn i innholdet, noe som sannsynligvis er hva folk flest er på nettstedet ditt for i første omgang. Tilpass denne modellen etter behov for nettstedet ditt, men husk alltid nøyaktig hva som vil være av interesse for de besøkende, og plasser det så nær toppen av koden som mulig.
Pass på at alle funksjoner på nettstedet ditt er mulige i dette grunnleggende laget. Det betyr at skjemaer og programmer burde være brukbare med bare HTML og server-side scripting. Selv om det er sannsynlig at funksjonaliteten ikke vil bli så godt presentert som du vil eller som brukervennlig, bør den være brukbar som et minimum.
Presentasjonen er Neste
Når HTML og grunnleggende funksjonalitet er angitt, vil du slå til presentasjonselementer. De aller fleste nettlesere, inkludert mange mobile nettlesere, støtter CSS (men ikke alle av dem støtter alle aspekter av CSS, spesielt CSS3). Presentasjonsnivået bør forbedre innholdet. Det skal gjøre det enklere å se og bruke, og forbedre brukeropplevelsen.
I noen grad her kan du ha mer enn ett lag med CSS-forbedring. Den første bør fokusere på grunnleggende stiler som er anerkjent av nesten alle moderne nettlesere. Din layout, typografi og fargevalg bør alle inkluderes i dette laget, sammen med andre stilistiske valg.
Deretter legger du til et annet lag utover det som utnytter mer avanserte egenskaper som kanskje ikke støttes av alle nettlesere der ute, men vil legge til brukeropplevelsen for de som bruker nettlesere som inkluderer støtte.
JavaScript burde være sist
Noen ganger virker det som om JavaScript brukes i nesten alle nye nettsider som er opprettet. JavaScript kan i stor grad bidra til brukervennlighet og brukeropplevelse av et nettsted eller en webapp.
Ajax har revolusjonert måten mange nettsteder fungerer, og har gjort en stor forskjell i det vi nå gjør online. Men nettstedet ditt eller appen skal fungere uten JS. Det bør alltid være et HTML-alternativ eller en server-side scripting alternativ, spesielt når vi snakker om generelle nettsteder i stedet for web apps.
Sørg for at nettstedet ditt kan brukes uten JavaScript. Mens de fleste nettbrukere har JS aktivert i nettleseren sin, er det fortsatt tilfeller der JavaScript er uønsket. Ikke alle mobile nettlesere der ute har god støtte til JavaScript. Det er ofte ikke tilgjengelig for skjermlesere. Og det er noen mennesker der ute som fortsatt ikke har aktivert JavaScript i nettleserne sine.
Som du kan se fra skjermbildene nedenfor, er det ingen funksjonalitet tapt mellom den JavaScript-aktiverte versjonen av Alfred app-nettstedet og den med JavaScript slått av. Den eneste virkelige forskjellen er at vilkårene og betingelsene er forankret nederst på siden, i stedet for å åpne i et modalt vindu når koblingen klikkes. Men i begge tilfeller er de koblet og fullt lesbare.
Her er den fullt funksjonelle versjonen av nettstedet, med det modale vinduet.
Her er versjonen med JavaScript deaktivert, med vilkårene og betingelsene som vises like over bunnen. Den er fortsatt koblet fra samme sted i innholdet.
Implementere Progressiv Forbedring
Vi har snakket om PE på et teori-nivå over. Men la oss komme inn i de praktiske aspektene ved å implementere det på et nettsideprosjekt. Det første du må gjøre er å finne ut informasjonarkitekturen for nettstedet ditt.
Se på innholdet som er tilgjengelig og hvordan det skal organiseres. Opprett noen wireframes for hvordan du vil vise innholdet, plasseringen av forskjellige elementer, etc. Prioritere dem på dette tidspunktet, etter hva som skal vises nærmest toppen av koden (de viktigste elementene) og hva som kan gå ned lavere.
Dette informasjonsarkitekturstrinnet er viktig med progressiv forbedring. Når du vet hva som må gå der, kan du starte kodingen. Pass på at du setter opp HTML-koden i riktig rekkefølge, i henhold til det som er viktigst. Dette trenger ikke nødvendigvis å falle sammen med ordren der ting vises på ditt ferdige, stilige nettsted, men det er sannsynligvis ikke for langt unna (topptekst, innhold i midten, bunntekst nederst).
Pass på at HTML-en du kodes her er semantisk. Bruk riktig , , koder, etc., så vel som riktig navngi divene der innholdet ditt vises. Dette gjør det ikke bare mer tilgjengelig, men gjør det også enklere å opprettholde koden og koding av CSS.
Du vil også koden i en hvilken som helst funksjonalitet på dette tidspunktet ved å bruke server-side-skript. Mens det endelige nettstedet ditt kan bruke Ajax til primær funksjonalitet, er det fortsatt viktig å ha en server-side backup, bare i tilfelle.
Når din grunnleggende HTML er ferdig, vil du gå videre til presentasjonslaget. Gå om dette i stor grad som du ville utformingen av et hvilket som helst nettside prosjekt. Men vær sikker på at når du kommer til å faktisk kode CSS at du opprettholder ideen om at ikke alle CSS-egenskaper vil fungere i hver nettleser. Sørg for at selv om noen av dine valgorer ikke virker, vil den generelle presentasjonen være upåvirket.
En liten bit av grasiøs nedbrytning kan være hensiktsmessig for noen av CSS, for de tilfellene når du virkelig vil bruke en bestemt teknikk som ikke er mye støttet. Det er ikke noe galt med å bruke det selektivt, i spesielle tilfeller. Men målet her er å stole på god, standardbasert koding og semantisk markering for å gjøre grasiøs nedbrytning unødvendig.
Det har vært litt diskusjon om hvorvidt bruk av flere stilark for progressiv forbedring er en god ide. Å skille ut de ulike aspektene av presentasjonen din (layout, typografi, farge osv., Samt forskjellige stilark for ting som utskrifts- eller mobiloppsett) kan være fornuftig, spesielt hvis stilarket ditt er langt eller komplisert.
Separate stilark gjør det lettere å finne et bestemt element, og kan gjøre det enklere og mer komplisert å vedlikeholde nettstedet. Tross alt, hvis du bare vil endre en farge, er det lettere å åpne fargestilarket og finne alle forekomster av fargen, og vet at du ikke har gått glipp av noe. Men la oss si at du vil endre fargen og typografien til en bestemt type element på siden din (som alle dine H1s eller sidebarene dine). Du må åpne flere stilark for å gjøre endringene. Enten du bruker flere CSS-filer eller ikke, kommer ned mer til personlig valg enn noe annet.
Når CSS er kodet og alt er testet, er det på tide å legge til noen skript på klientsiden. På dette tidspunktet skal nettstedet ditt fungere med eller uten JavaScript. Men å legge til JS kan i stor grad forbedre brukeropplevelsen og tilfredsheten. Når du har lagt til alle nødvendige skript, må du forsikre deg om å teste nettstedet igjen med at skriptet er slått av, for å sikre at alt fungerer fortsatt akseptabelt.
Overbevise kundene dine
Når du arbeider på egen hånd, er personlige nettsider, progressiv forbedring noe du kan implementere uten problemer. Når det gjelder å håndtere kunder, kan det imidlertid bli litt vanskeligere. Mange klienter er fortsatt fast på ideen om at deres nettside må vises nøyaktig det samme i hver nettleser de noensinne har brukt. Noen gang.
Forklar fordelene med progressiv forbedring til kundene dine. Fortell dem at det er raskere og billigere for dem å få deg til å designe nettstedet med progressiv forbedring i tankene, og at deres besøkende sannsynligvis ikke bryr seg uansett, så lenge innholdet er tilgjengelig.
Hvis de fremdeles motstår, fortell dem at du må justere sitatet tilsvarende for å kompensere for ekstra kodingstid og krefter som kreves.
I mange tilfeller, når en klient ser at den progressive forbedringen vil spare penger uten å skade sine besøkende, er de mer enn glade for at du kan designe deres nettsted på den måten.
Tilfeldig Progressiv Forbedring
Jeg er sikker på at det er noen blant dere som leser denne artikkelen og tenker: "Men dette er hvordan jeg designer nettsteder uansett!" Mange designere der ute, utformer sine nettsteder rundt innholdet, og sørger for at hvert lag er funksjonelt før du legger til en annen lag.
HTML-koden er godt strukturert, deres CSS fungerer som en helhet, men ser fortsatt bra ut, selv om ett eller to elementer ikke fungerer ordentlig, og selv uten klientside-skripting virker alt fortsatt.
Noen designere har selvsagt tatt en progressiv forbedringsdesign i webdesign. For de designerne ser denne artikkelen ut som en gammel hatt.
Men for de av dere der ute som tar motsatt tilnærming, enten med grasiøs nedbrytning, eller bare å designe for den laveste fellesnevneren og ikke plage med mer avanserte teknikker, bør du vurdere progressiv forbedring for ditt neste prosjekt.
Skrevet utelukkende for WDD av Cameron Chapman .
Planlegger du automatisk nettsteder med progressiv forbedring i tankene? Eller foretrekker du å ta en grasiøs nedbrytning tilnærming? Vennligst del dine strategier i kommentarene!