Parhaita käytäntöjä Web-suunnittelun progressiiviseen parantamiseen

Verkkosivujen rakentaminen on uskomattoman monimutkainen monien nopeasti muuttuvien osien kanssa. Verkkosuunnitteluyhteisön tavoitteena on vähentää monimutkaisuutta, ja vähentää mahdollisia virheitä luomisprosessin jokaisessa vaiheessa.

Progressiivinen parannus on tällainen idea web-suunnittelussa, jonka tavoitteena on vähentää virheitä ja tarjota yhdenmukainen käyttäjäkokemus kautta linjan. Konseptilla on oma Wikipedia-sivu, joka selittää sen menetelmänä täysin saatavilla oleva sisältö, parantaa ominaisuuksia vain selaimen tukemana.

On helppo ymmärtää progressiivista parannusta, mutta ei ole niin helppoa soveltaa sitä suoraan suunnittelutyöhön. Haluaisin kattaa joitakin parhaiden käytäntöjen kehittäminen reaalimaailman hankkeiden asteittaiseen parantamiseen että auttaa suunnittelijoita ajattelemaan kestävämmin työnkulusta.

1. Progressiivisen parantamisen ymmärtäminen

Progressiivisen parantamisen teoria suosittelee aloita yksinkertaisella verkkosivustolla joka toimii kaikissa selaimissa kaikille vierailijoille. Lisää sitten ominaisuuksia aina kun se on mahdollista.

Tämä on vastakohta vastenmieliselle hajoamiselle, joka sisältää oletusarvoisesti kaikki ominaisuudet, ja sitten hajoaa, kun jokin ei toimi.

Progressiivinen parannus on parempi yleisen käyttäjäkokemuksen kannalta, koska sen ytimessä lataa vain tarvittavat osat. Jokainen selain voi tukea tekstiä (ja yleensä kuvia). Ilman CSS: ää nämä tiedot näyttävät suloisilta ja mauttomilta, mutta ne ovat saatavilla.

Tämä Luettelon lisäksi artikkelissa väitetään, että progressiivinen lisäys on content-first kanssa tyylit ja dynaamiset komponentit lisätään myöhemmin. Semanttisen HTML-sisällön sisältö on toimitettava ennen muuta.

Tänään käyttämämme kehittynyt CSS ja JavaScript ovat laajalti tuettuja, mutta jos haluamme noudattaa progressiivisen parantamisen periaatteita, niitä on pidettävä ylellisinä.

Seuraavassa on yleistynyt asteittaisen lisälaitteen pääpiirteet, jotka sinun on otettava huomioon:

• Semanttinen merkintä kaikki sisällöt
• käyttäjien selainasetukset on kunnioitettava
• Sisällön ja perustoimintojen tulisi olla kaikkien käyttäjien käytettävissä
• Tuntematon JavaScript ladataan vain ympäristöissä, jotka voivat tukea sitä

Etupään kehitykseen liittyvät teknologiset rajoitukset määräytyvät ensisijaisesti selaimen yhteensopivuuden perusteella. Progressiivinen parannus saa sinut takaisin perusasioihin ajattelemalla miten paljain luun yksinkertaisin verkkosivu saattaa näyttää. Sieltä voit suunnitelma kehittyneemmistä ominaisuuksista, kuten CSS3-ominaisuudet.

Mutta entä selaimet, jotka eivät tue nykyistä CSS3: ta? Tämä on paikka, jossa sivustot, kuten Can I Use, tulevat pelaamaan. Sinun pitäisi päättää, mitkä ominaisuudet kannattaa toteuttaa ja tehdä tuomioita sivustosi kohdeyleisölle.

2. Tyylilehdet

Useimmat selaimet tukevat tänään kaikkia tarvittavia perusominaisuuksia. Mutta kehittynyt CSS3 on edelleen ongelma vanhemmille käyttäjille, ja progressiivinen parannus tarjoaa ratkaisun.

Ennen kuin etsit varmuuskopiointimenetelmiä näiden uusien ominaisuuksien ylläpitämiseksi, olkaa huolissasi ensin asianmukaiset asettelurakenteet.

Kirjoita semanttinen HTML ja CSS-merkintä, joka toimii mahdollisimman monissa aktiivisissa selaimissa (tuki muille selaimille, kuten IE5-tuki, ei ole tarpeen).

Otetaan esimerkiksi tämä JSFiddle, joka käyttää kelluvia kaksi sivupalkkia (.kiinteä) ja nestemäisen sisällön alue (.neste). Jos poistat kaikki CSS: n ja käynnistät koodin, jonka huomaat, kaikki pinot kasvavat hienosti ensimmäisen sarakkeen, sitten toisen ja lopuksi viimeisen.

Jotkut kehittäjät haluaisivat sisällön sarakkeen (.neste) näkyvät ensin HTML: ssä. Tässä vaiheessa progressiivinen parannus tulee voimaan, ja vaihtoehtoiset CSS-ratkaisut tulevat elinkelpoisiksi.

HTML: n kaksi päätavoitetta ovat seuraavat:

• Täysin semanttinen ja pätevä koodi
• johdonmukainen kokemus kaikille

Yksinkertaisin tapa saavuttaa nämä tavoitteet on aloita mitään ja työtä, koska useimmat progressiiviset lisäedustajat suosittelevat sitä.

Jos koodi näyttää hyvältä CSS: n ollessa sekä poissa käytöstä että käytössä, se tarjoaa kohtuullisen ratkaisun kaikille.

On myös syytä harkita missä vaiheessa pudotat tukea jollekin. Microsoft on jo pudonnut suurta tukea IE6: lle, joten selaimen käynnissä olevat käyttäjät eivät välttämättä kannata aikaa.

Mutta on vielä yksi suuri kysymys: jos selain ei tue nykyaikaista CSS: ää, mitä minun pitäisi tehdä?

Olet yksinkertaisesti kirjoita koodi, joka toimii ilman se, ja pitää nykyaikainen CSS progressiivisena parannuksena. Tämä on progressiivisen parannusmenetelmän kauneus.

Sinun ei tarvitse hukkua, koska olet periaatteessa olettaen, että mitään ei tueta oletusarvoisesti.

Progressiiviset parannusmenetelmät tekevät sivuston käyttökelpoisuudesta jopa silloin, kun jotain ei tueta, mutta jos sitä tuetaan, sitä parempi.

Sinun täytyy harkita miten sisältö kulkee ilman CSS: ää. Esimerkiksi, kun poistan CSS-palvelun lähetyssivustolla, sisältö virtaa edelleen orgaanisesti alaspäin sivulta.

Kyllä, se on ruma, ja kyllä, tuntuu siltä, ​​että olemme menettäneet kaksikymmentä vuotta edistystä… mutta se toimii.

3. JavaScriptin käsittely

On syytä mainita, että jokainen JavaScript-ongelma, jonka saatat törmätä kehitystyön aikana, on hankala ja ainutlaatuinen. Kun rakennat uuden projektin, jossa on progressiivinen parannus, sinun on lueteltava kaikki tarvittavat JS-pohjaiset ominaisuudet ja harkittava, miten ne voisivat toimivat ilman JavaScriptiä.

Tämä edellyttää paljon verkkotutkimusta, jotta löydettäisiin kelvollisia ratkaisuja. Aaron Gustafson kirjoitti suuren blogipostin, jossa on ratkaisuja erilaisiin ongelmiin, kuten Ajaxin korvaaminen sisällön päivitykseen iframe-sisällön sisällä.

Kun luot JavaScript-välilehdet, se on hyvä idea Käytä ankkurilinkkejä, joilla on todellisia ID-arvoja. Tällä tavoin, kun JavaScript on poistettu käytöstä, voit silti nähdä, että välilehdet näkyvät ja ne ovat saatavilla ankkuriarvolla. Aaron kirjoitti toisen kappaleen A List Apartiin, joka kattaa yleisemmän katsauksen siitä, miten sinun pitäisi ajatella näitä ongelmia.

Tässä on toinen esimerkki. Oletetaan, että sinulla on linkki, joka ladaa sisältöä dynaamisesti. href arvo on tyhjä, koska kaikki lataa JavaScriptin avulla estdefault () -menetelmällä.

Sen sijaan olisi viisasta asettaa href omaisuutta osoita eri sivulle jossa sisältö voi ladata luonnollisesti, mutta kävijä näkee kyseisen sivun vain, kun JavaScript on poistettu käytöstä.

Progressiivinen parannus on enemmän kuin JavaScript, mutta web-kehitystyöllä edistetään joka vuosi, eikä ole epäilystäkään siitä, että JavaScript on merkittävä rooli.

Käytä sitä olettaen, että kaikki on poistettu käytöstä, ja laajentaa sieltä. Tämä voi sisältää ongelmia sulautettujen widgetien kanssa, jotka eivät ole hallittavissa

Ajattele myös JavaScript-ominaisuuksia puuttuu kattava selaintuki. Tämä sisältää hakuradan API: n, push API: n, nuolitoimintojen syntaksin tai jopa selaimet, jotka eivät tue nykyisiä kirjastoja kuten jQuery.

Jokainen ominaisuus vaatii yksilöllinen testaus yksilöllinen ratkaisu.

Jatkuvasti tehostetun JavaScriptin olemus on rakentaa sisältöä, joka toimii ilman skriptejä. Tämä voi johtaa alkeelliseen käyttäjäkokemukseen, mutta se on kunnossa niin kauan kuin sivusto on käyttökelpoinen ja sisältö on saatavilla.

Jos haluat tehdä suoran testauksen, voit tyypillisesti poista CSS ja JavaScript käytöstä kaikissa tärkeimmissä selaimissa nähdä, miten sivustosi toimii. Lisäksi kannattaa harkita sellaisten laajennusten käyttöä, kuten A-Tester WCAG: n noudattamista varten.

JavaScript, jossa on progressiivinen lisäys, on valtava aihe. Tässä on muutamia viestejä, joiden avulla voit kaivaa syvemmälle:

• Progressiivinen parannus! = “Ei JavaScript”
• Vuorovaikutus on avain: progressiivinen parannus ja JavaScript
• Progressiivinen parannus: se on sisällöstä
• Progressive Enhancement -toiminnon käyttäminen, kun JavaScript näyttää olevan vaatimus

Jos Progressive Enhancement -toiminto on lyhyt

Vaikka progressiivinen parannus on loistava idea lähes kaikentyyppisille nykyaikaisille verkkosivuille, se voi yksinkertaisesti olla ei sovelleta hankkeisiin, joiden tarkoituksena on rajoittaa web-tekniikan rajoja.

Esimerkiksi tämä menetelmä ei ole hyvä ratkaisu web-sovelluksiin, jotka toimivat vain Ajax-puheluilla. Onko se hyvä valinta saavutettavuuteen? Ei tietenkään. Mutta jos näin olisi, useimmat Codropsin opetusohjelmat eivät olisi edes olemassa. Sinun täytyy muista kohdeyleisöä.

Yrityksen verkkosivustolla ei todennäköisesti ole yleisöä, joka välittää räikeistä uusista CSS3-näkymän ominaisuuksista, mutta web-kehittäjät voivat olla täydellinen yleisö tällaisille lisätoiminnoille.

Progressiivinen parannus puuttuu vain web-sovelluksiin yksinkertaisesti ei välitä ajasta takaisin. Ymmärrän, että nämä web-sovellukset ovat vain vähän ja kaukana toisistaan, mutta kehittäjät rakastavat edistystä, ja joissakin tapauksissa voi olla järkevää edetä uusilla teknologioilla, jolloin stragglerit jäävät taakse.

Kannatan yleisiä verkkoprojekteja progressiivisesti (tai jopa graceful degradation, your choice). Mutta ymmärrän, että se ei ole täydellinen ratkaisu kaikelle. Itse asiassa ei ole täydellinen ratkaisu. Kaiken kaikkiaan se kohdistuu yleisön tarpeisiin ja hankkeen tavoitteisiin.

Lue lisää

Jos rakennat jatkuvasti verkkoprojekteja, kannattaa harkita työnkulun asteittaista parantamista. Se on paljon helpompaa kuin ensi silmäyksellä, ja kaikki alkaa perusasioista. Useimmat progressiivista parannusta koskevat aiheet edellyttävät vain käytäntöä ja testausta. Kokeile tämän artikkelin ehdotuksia ja katso, mikä toimii parhaiten työnkulussa.

Jos haluat lisätietoja progressiivisesta parannuksesta, tutustu näihin liittyviin viesteihin:

• Progressiivisen parantamisen ymmärtäminen
• Progressiivinen parannus: mitä se on ja miten sitä käytetään?
• JavaScript-riippuvuussuhde: myytti-busting progressiivinen parannus