Praktische tips voor een progressieve verbetering van webontwerp

Het ambacht van het bouwen van websites is ongelooflijk complex met veel snel veranderende onderdelen. Het doel van de webontwerpgemeenschap is om de complexiteit verminderen, en verminder het potentieel voor fouten in elke fase van het creatieproces.

Progressieve verbetering is zo'n idee in webdesign dat streeft naar fouten verminderen en zorg voor een consistente gebruikerservaring over de hele linie. Het concept heeft een eigen Wikipedia-pagina die het als een methode van uitlegt volledig toegankelijke inhoud, renderen van verbeterde functies alleen wanneer dit wordt ondersteund door de browser.

Het is gemakkelijk om progressieve verbeteringen te begrijpen, maar niet zo eenvoudig om het rechtstreeks toe te passen op uw ontwerpwerk. Ik zou graag wat willen bespreken best practices voor progressieve verbetering in real-world projecten naar ontwerpers helpen duurzamer na te denken over hun workflow.

1. Progressive Enhancement begrijpen

De theorie van progressieve verbetering beveelt aan begin met een eenvoudige website dat werkt in alle browsers, waardoor het wordt toegankelijk voor elke bezoeker. Voeg vervolgens waar mogelijk functies toe.

Dit is het tegenovergestelde van sierlijke degradatie die standaard alle functies omvat, en vervolgens wordt verlaagd wanneer iets niet werkt.

Progressieve verbetering is beter voor de algehele gebruikerservaring, omdat dit in de kern het geval is laadt alleen noodzakelijke elementen. Elke webbrowser kan tekst (en meestal afbeeldingen) ondersteunen. Zonder CSS zal deze informatie saai en smaakloos lijken, maar deze zal toegankelijk zijn.

Deze Lijst apart artikel betoogt dat progressieve verbetering is Inhoud-first met stijlen en dynamische componenten later toegevoegd. Inhoud in semantische HTML moet vóór alles worden geleverd.

De geavanceerde CSS en JavaScript die we tegenwoordig gebruiken, worden breed ondersteund, maar als we de principes van progressieve verbetering willen volgen, moeten ze als luxe worden beschouwd.

Hier volgt een algemeen overzicht van de belangrijkste kenmerken van progressieve verbetering, waarmee u rekening moet houden:

Semantische opmaak voor alle inhoud
Users' browser voorkeuren moet worden gerespecteerd
Inhoud en basisfunctionaliteit zou moeten zijn beschikbaar voor alle gebruikers
Onopvallend JavaScript is alleen geladen in omgevingen die dit kunnen ondersteunen

Technologische beperkingen in de front-end ontwikkeling worden voornamelijk bepaald door browsercompatibiliteit. Progressive Enhancement brengt je terug naar de basis en denkt na over hoe het bare-bone meest eenvoudige webpagina zou er uit kunnen zien. Vanaf daar kunt u plan voor meer geavanceerde functies, zoals CSS3-eigenschappen.

Maar hoe zit het met browsers die moderne CSS3 niet ondersteunen? Hier komen sites als Can I Use om de hoek kijken. U moet beslissen welke functies de moeite waard zijn om te implementeren en u moet oordelen op de doelgroep van uw website.

2. Verblijf in stylesheets

De meeste browsers ondersteunen tegenwoordig alle basiseigenschappen die u nodig hebt. Maar geavanceerde CSS3 is nog steeds een probleem voor oudere gebruikers, en progressive enhancement biedt een oplossing.

In plaats van op zoek te gaan naar fallback-methoden om deze nieuwe functies te behouden, moet u zich eerst bezighouden met juiste lay-outstructuren.

Schrijf semantische HTML- en CSS-markeringen die in zoveel mogelijk actieve browsers werken (ondersteuning voor oude browsers zoals IE5-ondersteuning is niet nodig).

Neem bijvoorbeeld deze JSFiddle die drijvers gebruikt met twee zijbalken (.vast), en een gebied met vloeibare inhoud (.vloeistof). Als u alle CSS verwijdert en de code opnieuw uitvoert, merkt u dat alles goed verloopt in de eerste kolom, daarna op de tweede en uiteindelijk in de laatste kolom..

Sommige ontwikkelaars geven er de voorkeur aan de inhoudskolom te hebben (.vloeistof) verschijnen als eerste in de HTML. Dit is waar progressieve verbetering in het spel komt en alternatieve CSS-oplossingen levensvatbaar worden.

De twee hoofddoelen van uw HTML zijn als volgt:

Geheel semantisch en geldig code
EEN consistente ervaring voor iedereen

De meest eenvoudige manier om deze doelen te bereiken, is start vanuit niets en opbouwen, aangezien de meeste progressieve bevorderingsadvocaten het zouden adviseren.

Als uw code er goed uitziet met CSS zowel uitgeschakeld als ingeschakeld, dan biedt het een redelijke oplossing voor iedereen.

Het is ook het overwegen waard op welk punt je ondersteuning voor iets laat vallen. Microsoft heeft al grote ondersteuning voor IE6 uitgebracht, dus gebruikers die die browser gebruiken, zijn misschien niet de moeite waard.

Maar er is nog steeds een grote vraag: als een browser mijn moderne CSS niet ondersteunt, wat moet ik dan doen??

Jij gewoon schrijf code die werkt zonder het, en beschouw de moderne CSS als een progressieve verbetering. Dit is de schoonheid van de progressieve verbeteringsmethode.

Je hebt geen fallbacks nodig, omdat je dat bent in de veronderstelling dat niets standaard wordt ondersteund.

Progressieve verbeteringsmethoden hebben betrekking op het bruikbaar maken van de site, zelfs in gevallen waarin iets niet wordt ondersteund, maar als het wordt ondersteund, des te beter.

U moet overwegen hoe inhoud eigenlijk zonder CSS vloeit. Wanneer ik bijvoorbeeld CSS op de website van Transmit uitschakel, vloeit de inhoud nog steeds organisch door de pagina.

Ja, het is lelijk, en ja, het voelt alsof we twintig jaar vooruitgang hebben verloren ... maar het werkt.

3. Omgaan met JavaScript

Het is de moeite waard te vermelden dat elk JavaScript-probleem dat u tegenkomt tijdens het ontwikkelingsproces, lastig en uniek is. Wanneer u een nieuw project bouwt met een progressieve verbetering, moet u al uw vereiste op JS gebaseerde functies vermelden en bekijken hoe ze dit kunnen werken zonder JavaScript.

Dit vereist veel online onderzoek om geldige oplossingen te vinden. Aaron Gustafson schreef een geweldige blogpost met oplossingen voor verschillende problemen, zoals Ajax vervangen door een meta refresh voor inhoud in een iframe.

Ook wanneer u JavaScript-tabbladen maakt, is het een goed idee om dit te doen gebruik ankerlinks met echte ID-waarden. Op die manier kunt u, wanneer JavaScript is uitgeschakeld, de tabbladen nog steeds zichtbaar en toegankelijk maken per ankerwaarde. Aaron schreef nog een stuk over A List Apart dat een meer algemeen overzicht bevat van hoe je over deze problemen zou moeten nadenken.

Hier is nog een voorbeeld. Stel dat u een koppeling heeft die inhoud dynamisch laadt. De href waarde is leeg, omdat alles via JavaScript wordt geladen met de methode preventDefault ().

In plaats daarvan zou het verstandig zijn om de href eigendom van naar een andere pagina wijzen waar de inhoud natuurlijk kon laden, maar de bezoeker ziet die pagina alleen als JavaScript is uitgeschakeld.

Progressive Enhancement gaat over meer dan alleen JavaScript, maar met webontwikkeling die elk jaar verder gaat, is er geen twijfel dat JavaScript een belangrijke rol speelt.

Bedien in de veronderstelling dat alles is uitgeschakeld, en opschalen vanaf daar. Dit kan problemen zijn met ingesloten widgets die buiten uw controle zijn, de