Parimad tavad veebidisaini järkjärguliseks täiustamiseks

Veebilehtede ehitamine on paljude kiirelt muutuvate osadega väga keeruline. Veebidisaini kogukonna eesmärk on vähendada keerukust, ja vähendada võimalikke vigu loomise protsessi igas etapis.

Järkjärguline täiustamine on selline idee veebidisainis, mille eesmärk on vähendada vigu ja pakkuda järjepidevat kasutaja kogemust kõikjal. Kontseptsioonil on oma Wikipedia leht, mis selgitab seda kui meetodit täielikult kättesaadav sisu, täiustatud funktsioonide esitamine ainult brauseri toel.

Progresseeruvat täiustamist on kerge mõista, kuid mitte nii lihtne seda otse oma disainitööle rakendada. Ma tahaksin katta mõned tegelike projektide järkjärgulise täiustamise parimad tavad kuni aidata disaineritel mõelda jätkusuutlikumalt oma töövoo üle.

1. Progressiivse täiustamise mõistmine

Järkjärgulise täiustamise teooria soovitab alustage lihtsa veebisaidiga mis töötab kõikides brauserites, tehes selle kättesaadav kõigile külastajatele. Seejärel lisage võimalused alati.

See on vastukaal graatsilisele halvenemisele, mis sisaldab kõiki funktsioone vaikimisi, seejärel halveneb, kui midagi ei tööta.

Progressiivne täiustamine on üldise kasutajakogemuse jaoks parem, sest selle keskmes on see laadib ainult vajalikud elemendid. Iga veebibrauser toetab teksti (ja tavaliselt pilte). Ilma igasuguse CSS-i nägemata on see teave ebamugav ja maitsetu, kuid see on kättesaadav.

See Nimekiri artikkel väidab, et progressiivne täiustamine on sisu-esimene koos hiljem lisatud stiilid ja dünaamilised komponendid. Semantilise HTML-i sisu tuleb esitada enne midagi muud.

Tänapäeval kasutatav arenenud CSS ja JavaScript on laialdaselt toetatud, kuid kui me tahame järgida järkjärgulise täiustamise põhimõtteid, tuleks neid pidada luksuslikeks.

Alljärgnevalt on esitatud üldine halvenemine progressiivse täiustamise peamistest omadustest, mida peaksite arvesse võtma:

• Semantiline märgistus kogu sisu jaoks
• Kasutajad brauseri eelistused tuleb austada
• Sisu ja põhifunktsioonid peaksid olema kõigile kasutajatele
• Unctrusive JavaScript on laaditud ainult keskkonnas, mis seda toetavad

Tehnoloogilised piirangud esikülje arendamisel sõltuvad peamiselt brauseri ühilduvusest. Järkjärguline täiustamine viib teid tagasi põhitõedesse, mõteldes, kuidas palja luu lihtsaim veebileht võib tunduda. Sealt saate täiustatud funktsioonide plaan, nagu CSS3 omadused.

Aga kuidas brauserid ei toeta kaasaegset CSS3? Siin mängitakse selliseid saite nagu Can I Use. Te peaksite otsustama, milliseid omadusi tasub rakendada ja teha otsuseid teie veebisaidi sihtrühmale.

2. Toimetulek stiililehtedel

Enamik brausereid toetab täna kõiki vajalikke põhilisi omadusi. Aga arenenud CSS3 on endiselt probleem vanematele kasutajatele, ja järkjärguline täiustamine pakub lahendust.

Selle asemel, et otsida uusi meetodeid nende uute funktsioonide säilitamiseks, muretsege esmalt iseendaga nõuetekohased paigutusstruktuurid.

Kirjutage semantiline HTML ja CSS märgistus, mis töötab võimalikult paljudes aktiivsetes brauserites (toetus vanadele brauseritele nagu IE5 tugi ei ole vajalik).

Võtke näiteks see JSFiddle, mis kasutab ujukeid kahe külgribaga (.fikseeritud) ja vedeliku sisu ala (.vedelik). Kui kustutate kõik CSS-id ja käivitate uuesti koodi, mida täheldate, virnastab kõik esimene veerg, siis teine ​​ja lõpuks viimane.

Mõned arendajad eelistaksid sisu veergu (.vedelik) ilmuvad esmalt HTML-is. See on koht, kus progressiivne täiustamine mängib ja alternatiivsed CSS-lahendused muutuvad elujõuliseks.

Teie HTML-i kaks peamist eesmärki on järgmised:

• Täielikult semantiline ja kehtiv kood
• A järjepidev kogemus igaühele

Kõige lihtsam viis nende eesmärkide saavutamiseks on alustage mitte midagi ja ülestöötamine, kuna enamik progressiivseid täiustuse advokaate soovitaks seda.

Kui teie kood näeb hea välja CSS-iga nii keelatud kui ka lubatud, pakub see kõigile mõistlikku lahendust.

Samuti tasub kaaluda millal sa toetad midagi. Microsoft on juba langetanud suure toetuse IE6-le, nii et selle brauseri kasutajad ei pruugi oma aega väärt.

Kuid on veel üks suur küsimus: kui brauser ei toeta minu kaasaegset CSS-i, mida ma peaksin tegema?

Sa lihtsalt kirjutage kood, mis töötab ilma seda, ja kaaluge kaasaegset CSS-i kui progressiivset täiustamist. See on progressiivse täiustamise metoodika ilu.

Sa ei pea muret, sest sa oled põhimõtteliselt eeldades, et vaikimisi ei toeta midagi.

Progresseeruvad täiustamismeetodid on mõeldud selleks, et muuta sait kasutatavaks ka siis, kui midagi ei toetata, kuid kui seda toetatakse, seda parem.

Sa pead kaaluma kuidas sisu tegelikult voolab ilma CSS-i. Näiteks, kui keelan CSS-i saatelehel veebisaidil, voolab sisu ikka veel orgaaniliselt alla.

Jah, see on kole ja jah, tundub, et oleme kaotanud kakskümmend aastat edu… kuid see toimib.

3. JavaScripti käitlemine

Väärib märkimist, et iga JavaScripti küsimus, mida te arendusprotsessi käigus võidelda, on keeruline ja ainulaadne. Kui te ehitate progressiivse täiustamisega uut projekti, peate loendama kõik vajalikud JS-põhised funktsioonid ja kaaluma, kuidas neid saaks töötama ilma JavaScriptita.

See nõuab kehtivate lahenduste leidmiseks palju online-uuringuid. Aaron Gustafson kirjutas suurepärase blogipostituse erinevate probleemide lahendustega, nagu näiteks Ajaxi asendamine meta-värskendusega sisu sisuks iframe'is.

Ka JavaScript-vahekaartide loomisel on see hea mõte kasutage reaalsete ID-väärtustega ankursidemeid. Sel moel, kui JavaScript on keelatud, on teil ikka veel võimalik näha kaarte ja need on ligipääsetavad ankurväärtuse kaudu. Aaron kirjutas veel ühe teose A-nimekirjas, mis hõlmab üldisemat ülevaadet sellest, kuidas peaksite neid probleeme mõtlema.

Siin on veel üks näide. Oletame, et teil on link, mis laadib sisu dünaamiliselt. The href väärtus on tühi, sest kõik laadib JavaScript kaudu ära meetodiga PrevDefault ().

Selle asemel oleks mõistlik määrata href vara osuta teisele lehele kus sisu võib loomulikult laadida, kuid külastaja näeb seda lehte ainult siis, kui JavaScript on keelatud.

Järkjärguline täiustamine on rohkem kui JavaScript, kuid veebiarendust edasi arendades igal aastal, pole kahtlust, et JavaScript mängib olulist rolli.

Töötage eeldusel, et kõik on keelatud, ja ulatust. See võib hõlmata probleeme, mis on seotud sisseehitatud vidinatega, mis on teie kontrolli alt väljas

Mõelge ka JavaScript-funktsioonidele puudub põhjalik brauseri tugi. See hõlmab fetch API, push API, noolfunktsioonide süntaksit või isegi brausereid, mis ei toeta kaasaegseid raamatukogusid nagu jQuery.

Iga funktsioon nõuab individuaalne testimine individuaalse lahendusega.

Järkjärgult täiustatud JavaScripti olemus on luua sisu, mis toimib ilma skriptita. See võib kaasa tuua algelise kasutaja kogemuse, kuid see on korras, kui veebisait on kasutatav ja sisu on kättesaadav.

Kui soovite teha reaalajas teste, saate tavaliselt seda teha keelata CSS ja JavaScript igas suuremas brauseris et näha, kuidas teie veebisait toimib. Tasub kaaluda ka selliste laienduste kasutamist nagu A-Tester WCAG nõuetele vastavuse tagamiseks.

Progressiivse täiustamisega JavaScript on suur teema. Siin on mõned postitused, mis aitavad teil sügavamalt kaevata:

• Progressiivne täiustamine! “JavaScript puudub”
• Koostoime on võti: progressiivne täiustamine ja JavaScript
• Progressive Enhancement: see on sisu kohta
• Kuidas rakendada progressiivset täiustamist, kui JavaScript näib olevat nõue

Kui Progressive Enhancement Enhancement on lühike

Kuigi progressiivne täiustamine on suurepärane idee peaaegu igale kaasaegsele veebisaidile, võib see lihtsalt ei ole kohaldatav projektidele, mille eesmärk on tõsta veebitehnoloogia piire.

Näiteks see metoodika ei ole hea lahendus veebirakendustele, mis töötavad ainult Ajaxi kõnedel. Kas see on ligipääsetavuse jaoks hea valik? Ei, muidugi mitte. Aga kui see oleks nii, ei oleks enamik Codrops'i õpetusi isegi olemas olnud. Sa pead pidage meeles sihtrühma.

Ettevõtte veebisaidil ei ole ilmselt vaatajaskonda, kes hoolib uutest CSS3 perspektiivsetest omadustest, kuid veebiarendajad võivad olla selliste täiustatud funktsioonide jaoks täiuslik publik..

Järkjärguline täiustamine ei vasta veebirakendustele ainult lihtsalt ei hooli ajast tagasi minekust. Ma mõistan, et need veebirakendused on vähe ja kaugel, kuid arendajad armastavad edusamme ja mõnel juhul võib olla mõistlik edasi minna uute tehnoloogiatega, jättes stragglerid maha.

Ma pooldan üldiste veebiprojektide järkjärgulist täiustamist (või isegi graatsilist halvenemist, teie valikut). Kuid ma mõistan ka, et see ei ole ideaalne lahendus kõigile. Tegelikult pole täiuslikku lahendust. See kõik langeb publiku vajadustele ja projekti eesmärkidele.

Lisalugemist

Kui töötate pidevalt veebiprojekte, peaksite kaaluma oma töövoo järkjärgulist täiustamist. See on palju lihtsam, kui tundub esmapilgul, ja see kõik algab põhialustega. Enamik progressiivse täiustamise teemasid nõuavad ainult praktikat ja testimist. Proovige selle artikli soovitusi ja vaadake, mis teie töövoo jaoks kõige paremini sobib.

Kui soovite rohkem teada saada progressiivse täiustamise kohta, vaadake neid seotud postitusi:

• Progressiivse täiustamise mõistmine
• Progressive Enhancement: mis see on ja kuidas seda kasutada?
• JavaScript-sõltuvuse tagasilöök: müütide katkestamise progressiivne täiustamine