Bästa praxis för progressiv förbättring i webbdesign

Hantverket för att bygga webbplatser är oerhört komplicerat med många snabbt växande delar. Målet med webbdesignsgemenskapen är att minska komplexiteten, och minska risken för fel vid varje skede av skapandet.

Progressiv förbättring är en sådan idé i webbdesign som syftar till minska fel och ge en konsekvent användarupplevelse över hela linjen. Konceptet har sin egen Wikipedia-sida som förklarar det som en metod för fullt tillgänglig innehåll, Det gör endast förbättrade funktioner när de stöds av webbläsaren.

Det är lätt att förstå progressiv förbättring, men inte lika enkelt att tillämpa det direkt på ditt designarbete. Jag skulle vilja täcka några bästa praxis för progressiv förbättring i verkliga projekt till hjälpa designers att tänka mer hållbart om deras arbetsflöde.

1. Förstå Progressiv Förbättring

Teorin om progressiv förbättring rekommenderar att Börja med en enkel webbplats som fungerar i alla webbläsare, gör det tillgänglig för alla besökare. Lägg sedan till funktioner när det är möjligt.

Det här är motsatsen till graciös nedbrytning som inkluderar alla funktioner som standard och försämras då när något inte fungerar.

Progressiv förbättring är bättre för den övergripande användarupplevelsen, eftersom den är kärnan i den laddar endast nödvändiga element. Varje webbläsare kan stödja text (och vanligtvis bilder). Utan någon CSS kommer denna information att se blid och smaklös ut, men den kommer att vara tillgänglig.

Detta Lista Apart Artikeln hävdar att progressiv förbättring är innehålls första med stilar och dynamiska komponenter tillagda senare. Innehåll i semantisk HTML ska levereras innan något annat.

Den avancerade CSS och JavaScript som vi använder idag stöds brett, men om vi vill följa principerna om progressiv förbättring, bör de betraktas som lyx.

Här är en allmän översikt över huvuddragen i progressiv förbättring, som du bör ta hänsyn till:

• Semantisk uppmärkning för allt innehåll
• användare webbläsarpreferenser måste respekteras
• Innehåll och grundläggande funktionalitet bör vara tillgänglig för alla användare
• Diskret JavaScript är endast laddad i miljöer som kan stödja det

Tekniska begränsningar i front-end-utveckling bestäms primärt av webbläsarkompatibilitet. Progressiv förbättring får dig tillbaka till grunderna och tänker på hur enkelbens enklaste webbsida kan se ut. Därifrån kan du planera för mer avancerade funktioner, som CSS3 egenskaper.

Men vad sägs om webbläsare som inte stöder moderna CSS3? Det är här platser som kan jag använda kommer in i spel. Du bör bestämma vilka funktioner som är värda att genomföra, och göra bedömningar baserade på målgruppen på din webbplats.

2. Subsistence In Stylesheets

De flesta webbläsare stöder idag alla grundläggande egenskaper du behöver. Men avancerad CSS3 är fortfarande ett problem för äldre användare, och progressiv förbättring erbjuder en lösning.

Istället för att leta efter fallback metoder för att upprätthålla dessa nya funktioner, bekymra dig först med lämpliga layoutstrukturer.

Skriv semantisk HTML och CSS markup som fungerar i så många aktiva webbläsare som möjligt (stöd för gamla webbläsare som IE5-stöd är inte nödvändigt).

Ta till exempel den här JSFiddle som använder floats med två sidofält (.fast) och ett vätskeinnehållsområde (.vätska). Om du tar bort alla CSS och återställer koden märker du att allt staplar snyggt med den första kolumnen, sedan andra och äntligen den sista.

Vissa utvecklare föredrar att ha innehållskolumnen (.vätska) visas först i HTML. Det här är där progressiv förbättring kommer till spel, och alternativa CSS-lösningar blir lönsamma.

De två primära målen med din HTML är följande:

• Fullt semantisk och giltig koda
• en konsekvent erfarenhet för alla

Det enklaste sättet att uppnå dessa mål är att börja från ingenting och arbeta upp, som de flesta progressiva förbättringsförespråkare skulle rekommendera det.

Om din kod ser bra ut med CSS, både inaktiverad och aktiverad, erbjuder den en rimlig lösning för alla.

Det är också värt att överväga vid vilken tidpunkt slipper du stöd för något. Microsoft har redan tappat stort stöd för IE6, så användare som kör den webbläsaren kanske inte är värda din tid.

Men det finns fortfarande en stor fråga: Om en webbläsare inte stöder min moderna CSS, vad ska jag göra?

Du helt enkelt skriv kod som fungerar utan Det, och överväga den moderna CSS som en progressiv förbättring. Detta är skönheten i den progressiva förbättringsmetoden.

Du behöver inte fallbacks, för du är i princip antar att inget stöds som standard.

Progressiva förbättringsmetoder handlar om att göra webbplatsen användbar även i fall där något inte stöds - men om det stöds, desto bättre.

Du måste överväga hur innehållet faktiskt flyter utan CSS. När jag till exempel stänger av CSS på Transmit: s hemsida, flyter innehållet fortfarande organiskt ner på sidan.

Ja, det är fult, och ja, det känns som att vi har förlorat tjugo års framsteg ... men det fungerar.

3. Hantera JavaScript

Det är värt att nämna att varje JavaScript-fråga du kan stöta på under utvecklingsprocessen är knepig och unik. När du bygger ett nytt projekt med progressiv förbättring bör du lista alla dina nödvändiga JS-baserade funktioner och överväga hur de kunde fungera utan JavaScript.

Detta kräver mycket onlineforskning för att hitta giltiga lösningar. Aaron Gustafson skrev ett bra blogginlägg med lösningar på olika problem, som att ersätta Ajax med en meta refresh för innehåll inom en iframe.

När du skapar JavaScript-flikar är det också en bra idé att Använd ankarlänkar med riktiga ID-värden. På det sättet, när JavaScript är inaktiverat kan du fortfarande få flikarna synliga och tillgängliga med ankarvärde. Aaron skrev ett annat stycke på en lista som täcker en mer allmän översikt över hur du ska tänka på dessa problem.

Här är ett annat exempel. Låt oss säga att du har en länk som laddar innehållet dynamiskt. De href värdet är tomt, eftersom allt laddas via JavaScript med metoden preventDefault ().

Istället skulle det vara klokt att ställa in href egendom till peka på en annan sida där innehållet kan ladda naturligt, men besökaren ser bara den sidan när JavaScript är inaktiverat.

Progressiv förbättring handlar om mer än JavaScript, men med webbutveckling som går vidare varje år är det ingen tvekan om att JavaScript spelar en viktig roll.

Använd under antagandet att allt har blivit inaktiverat, och skala upp därifrån. Det här kan innebära problem med inbäddade widgets som du inte har kontroll över

Tänk också på JavaScript-funktioner som saknar omfattande webbläsarsupport. Detta inkluderar hämtnings API, push API, pilfunktionssyntaxen eller till och med webbläsare utan stöd för moderna bibliotek som jQuery.

Varje funktion kräver individuell testning med en individuell lösning.

Kärnan i progressivt förbättrad JavaScript är att bygga innehåll som fungerar utan skript. Detta kan leda till en rudimentär användarupplevelse, men det är okej så länge webbplatsen är användbar och innehållet är tillgängligt.

Om du vill göra levande test kan du vanligtvis inaktivera CSS och JavaScript i alla större webbläsare för att se hur din webbplats utför. Det är också värt att överväga att använda tillägg som A-Tester för WCAG-överensstämmelse.

JavaScript med progressiv förbättring är ett stort ämne. Här är några inlägg som hjälper dig att gräva djupare:

• Progressiv Förbättring! = “Ingen JavaScript”
• Interaktion är nyckel: Progressiv förbättring och JavaScript
• Progressiv Förbättring: Det handlar om innehållet
• Så här applicerar du progressiv förbättring när JavaScript verkar som ett krav

Där Progressiv Förbättring Faller Kort

Även om progressiv förbättring är en lysande idé för nästan alla typer av moderna webbplatser, kan det helt enkelt inte vara tillämpligt på projekt som syftar till att driva gränserna för webbteknik.

Till exempel är den här metoden inte en bra lösning för webbapplikationer som endast fungerar på Ajax-samtal. Är det ett bra val för tillgänglighet? Nej, självklart inte. Men om så var fallet skulle de flesta av Codrops tutorials inte ens existera. Du måste kom ihåg målgruppen.

En företagswebbplats har förmodligen inte publiken som bryr sig om flashiga nya CSS3-perspektivegenskaper, men webbutvecklare kan vara den perfekta publiken för sådana avancerade funktioner.

Progressiv förbättring faller bara för webbapplikationer som helt enkelt bryr sig inte om att gå tillbaka i tiden. Jag inser att dessa webbapplikationer är få och långt ifrån, men utvecklare älskar framsteg, och i vissa fall kan det vara vettigt att gå vidare med ny teknik som lämnar stragglersna bakom sig.

Jag är en förespråkare för progressiv förbättring (eller till och med graciös nedbrytning, ditt val) för allmänna webbprojekt. Men jag inser också att det inte är den perfekta lösningen för allting. Faktum är att det inte finns någon perfekt lösning. Allt kollar ner till publikens behov och projektmål.

Vidare läsning

Om du ständigt bygger webbprojekt, bör du överväga att tillämpa en progressiv förbättring av ditt arbetsflöde. Det är mycket lättare än det verkar vid första anblicken, och allt börjar med grunden. De flesta ämnen som rör progressiv förbättring kräver bara övning och testning. Prova förslaget från den här artikeln och se vad som bäst fungerar för ditt arbetsflöde.

Om du vill veta mer om progressiv förbättring, kolla in dessa relaterade inlägg:

• Förstå Progressiv Förbättring
• Progressiv förbättring: Vad det är och hur man använder det?
• JavaScript-beroendet Backlash: Mytstörande Progressiv Förbättring