Best Practices for Progressive Enhancement i Web Design

Håndværket ved at bygge hjemmesider er utrolig komplekst med mange hurtigt skiftende dele. Målet med webdesign samfund er at mindske kompleksiteten, og reducere muligheden for fejl på hvert trin i skabelsesprocessen.

Progressiv forbedring er sådan en ide i webdesign, der har til formål at reducere fejl og give en ensartet brugeroplevelse over hele linjen. Konceptet har sin egen Wikipedia side, som forklarer det som en metode til fuldt tilgængeligt indhold, Giver kun forbedrede funktioner, når de understøttes af browseren.

Det er nemt at forstå progressiv forbedring, men ikke så nemt at anvende det direkte på dit designarbejde. Jeg vil gerne dække nogle bedste praksis til progressiv forbedring i virkelige projekter til hjælpe designere til at tænke mere bæredygtigt om deres arbejdsgang.

1. Forståelse af progressiv forbedring

Teorien om progressiv forbedring anbefaler at Start med en simpel hjemmeside det virker i alle browsere, gør det tilgængelig for alle besøgende. Tilføj derefter funktioner, når det er muligt.

Dette er modsat af grasiøs nedbrydning, som alle funktioner omfatter som standard, og nedbrydes, når noget ikke virker.

Progressiv forbedring er bedre for den samlede brugeroplevelse, fordi den er kernen i den Indlæser kun nødvendige elementer. Hver webbrowser kan understøtte tekst (og normalt billeder). Uden CSS vil disse oplysninger se blid og smagløst ud, men det vil være tilgængeligt.

Dette Liste fra hinanden artiklen hævder, at progressiv forbedring er indholdsbaseret første med stilarter og dynamiske komponenter tilføjet senere. Indhold i semantisk HTML skal leveres før noget andet.

Den avancerede CSS og JavaScript, vi bruger i dag, støttes bredt, men hvis vi vil følge principperne om progressiv forbedring, bør de betragtes som luksus.

Her er en generel oversigt over hovedegenskaberne ved progressiv forbedring, som du bør tage højde for:

• Semantisk markering for alt indhold
• Brugere browser præferencer skal respekteres
• Indhold og grundlæggende funktionalitet skal være tilgængelig for alle brugere
• Diskret JavaScript er kun indlæst i miljøer, der kan understøtte det

Teknologiske begrænsninger i front-end-udvikling bestemmes primært af browserkompatibilitet. Progressiv forbedring får dig tilbage til det grundlæggende, tænker på hvordan bare-knogle enkleste webside kan se ud. Derfra kan du planlægge for mere avancerede funktioner, som CSS3 egenskaber.

Men hvad med browsere, der ikke understøtter moderne CSS3? Det er her, hvor websteder som Kan jeg bruge kommer ind i spil. Du bør beslutte, hvilke funktioner der er værd at implementere, og lave vurderinger baseret på målgruppen på dit websted.

2. Forhold i stilark

De fleste browsere understøtter i dag alle de grundlæggende egenskaber, du har brug for. Men avanceret CSS3 er stadig et problem for gamle brugere, og progressiv forbedring giver en løsning.

I stedet for at kigge efter tilbagesendelsesmetoder for at bevare disse nye funktioner, bekymre dig først med ordentlige layoutstrukturer.

Skriv semantisk HTML og CSS markup, der fungerer i så mange aktive browsere som muligt (støtte til gamle browsere som IE5 support er ikke nødvendig).

Tag for eksempel denne JSFiddle, der bruger flyder med to sidebjælker (.fast) og et fluidumindholdsområde (.væske). Hvis du sletter alt CSS og genopretter koden, vil du bemærke, at alt stabler fint sammen med den første kolonne, så anden og endelig den sidste.

Nogle udviklere foretrækker at have indholdskolonnen (.væske) vises først i HTML'en. Det er her, hvor progressiv forbedring kommer i spil, og alternative CSS-løsninger bliver levedygtige.

De to primære mål for din HTML er som følger:

• Fuldt ud semantisk og gyldig kode
• EN konsekvent oplevelse for alle

Den enkleste måde at nå disse mål på er at start fra ingenting og arbejde op, som de fleste progressive enhancement advocates ville anbefale det.

Hvis din kode ser godt ud med CSS både deaktiveret og aktiveret, så tilbyder den en rimelig løsning for alle.

Det er også værd at overveje på hvilket tidspunkt slipper du støtte til noget. Microsoft har allerede tabt større støtte til IE6, så brugere, der kører den browser, er måske ikke værd at din tid.

Men der er stadig et stort spørgsmål: Hvis en browser ikke understøtter mit moderne CSS, hvad skal jeg gøre?

Du simpelthen skrive kode, der virker uden det, og overveje det moderne CSS som en progressiv forbedring. Dette er skønheden i den progressive enhancement-metode.

Du behøver ikke fallbacks, fordi du er i det væsentlige forudsætter at intet understøttes som standard.

Progressive enhancement metoder handler om at gøre webstedet brugbart selv i tilfælde, hvor noget ikke understøttes-men hvis det understøttes, jo bedre.

Du skal overveje hvordan indhold rent faktisk flyder uden CSS. For eksempel, når jeg deaktiverer CSS på Transmit's hjemmeside, strømmer indholdet stadig organisk ned på siden.

Ja, det er grimt, og ja, det føles som om vi har mistet tyve års fremskridt ... men det virker.

3. Håndtering af JavaScript

Det er værd at nævne, at hvert JavaScript-problem, du kan støde på under udviklingsprocessen, er vanskelig og unik. Når du bygger et nyt projekt med progressiv forbedring, bør du liste over alle dine JS-baserede funktioner og overveje, hvordan de kunne operere uden JavaScript.

Dette vil kræve masser af online forskning for at finde gyldige løsninger. Aaron Gustafson skrev et stort blogindlæg med løsninger på forskellige problemer, som at erstatte Ajax med en meta refresh for indhold inden for en iframe.

Når du opretter JavaScript-faner, er det også en god ide at Brug ankerforbindelser med ægte ID-værdier. På den måde, når JavaScript er deaktiveret, kan du stadig få fanerne synlige og tilgængelige med ankerværdi. Aaron skrev et andet stykke på en liste fra hinanden, der dækker et mere generelt overblik over, hvordan du bør tænke på disse problemer.

Her er et andet eksempel. Lad os sige, at du har et link, der indlæser indhold dynamisk. Det href Værdien er tom, fordi alt indlæser via JavaScript med metoden preventDefault ().

I stedet ville det være klogt at sætte href ejendom til peg på en anden side hvor indholdet kunne indlæse naturligt, men den besøgende ser kun den side, når JavaScript er deaktiveret.

Progressiv forbedring handler om mere end JavaScript, men med udvikling af webudvikling yderligere hvert år er der ingen tvivl om, at JavaScript spiller en vigtig rolle.

Operere under antagelse om at alt er blevet deaktiveret, og skala op derfra. Dette kan omfatte problemer med indlejrede widgets, der er ude af din kontrol,

Tænk også på JavaScript-funktioner, som mangler omfattende browser support. Dette inkluderer hent API, push API, pilfunktions syntaks eller endda browsere uden support til moderne biblioteker som jQuery.

Hver funktion kræver individuel testning med en individuel løsning.

Essensen af ​​progressivt forbedret JavaScript er at opbygge indhold, der fungerer uden scripting. Dette kan føre til en rudimentær brugeroplevelse, men det er okay, så længe hjemmesiden er brugbar, og indholdet er tilgængeligt.

Hvis du vil gøre live test, kan du typisk deaktiver CSS og JavaScript i alle større browsere for at se, hvordan dit websted udfører. Det er også værd at overveje at bruge udvidelser som A-Tester til WCAG-overholdelse.

JavaScript med progressiv forbedring er et stort emne. Her er nogle indlæg, der hjælper dig med at grave dybere:

• Progressiv forbedring! = “Ingen JavaScript”
• Interaktion er nøgle: Progressiv forbedring og JavaScript
• Progressiv forbedring: Det handler om indholdet
• Sådan anvendes progressiv forbedring, når JavaScript ser ud som et krav

Hvor Progressiv Forbedring Faldes Kort

Selvom progressiv forbedring er en genial idé til næsten alle typer moderne hjemmesider, kan det simpelthen gælder ikke for projekter, der sigter mod at skubbe grænserne for webteknologi.

For eksempel er denne metode ikke en god løsning til webapplikationer, der kun fungerer på Ajax-opkald. Er det et godt valg for tilgængelighed? Nej selvfølgelig ikke. Men hvis det var tilfældet, ville de fleste af Codrops 'tutorials ikke engang eksistere. Du skal husk målgruppen.

En virksomhedswebsted har sandsynligvis ikke publikum, der bekymrer sig om prangende nye CSS3 perspektivegenskaber, men webudviklere kan være det perfekte publikum for sådanne avancerede funktioner.

Progressiv forbedring er kun kort for webapplikationer, som bare ligeglade med at gå tilbage i tiden. Jeg er klar over, at disse webapplikationer er få og langt imellem, men udviklere elsker fremskridt, og i nogle tilfælde kan det være fornuftigt at forfølge nye teknologier, der forlader stragglers bagved.

Jeg er en fortaler for progressiv forbedring (eller endda yndefuld nedbrydning, dit valg) til generelle webprojekter. Men jeg er også klar over, at det ikke er den perfekte løsning til alting. Faktisk er der ingen perfekt løsning. Det hele koger ned til publikums behov og projektmål.

Yderligere læsning

Hvis du konstant bygger webprojekter, bør du overveje at anvende progressiv forbedring til din workflow. Det er meget nemmere end det ser ud ved første øjekast, og det hele begynder med fundamentet. De fleste emner omkring progressiv forbedring kræver kun praksis og test. Prøv forslagene fra denne artikel, og se, hvad der virker bedst for din arbejdsgang.

Hvis du vil lære mere om progressiv forbedring, skal du tjekke disse relaterede indlæg:

• Forståelse af progressiv forbedring
• Progressiv forbedring: Hvad det er, og hvordan man bruger det?
• JavaScript-afhængighed Backlash: Myth-Busting Progressive Enhancement