Viime aikoina olen törmännyt paljon reagoivat verkkosivustot kanssa paljon suorituskykyyn liittyviä kysymyksiä. Useimmissa niistä ongelmat ovat niin ilmeisiä, että ne ovat melkein hyödyttömiä uusimman sukupolven älypuhelinten lisäksi. Ottaen huomioon, että reagointikykyä koska konseptin on tarkoitus saavuttaa a laajempi yleisölle, tämä vaikuttaa melko haitalliselta.

Suurin tekijä tässä asiassa on edelleen yleinen työpöydän ensimmäinen suunnitteluparadigma. Ajattelu ensin matkapuhelimen näkökulmasta näyttää ratkaisevan ongelman, mutta se yksinään ei takaa tyydyttävää suorituskykyä. Me kaikki näytämme luottavan aivan liian paljon enemmän tai vähemmän siroihin rappeutumiseen. Luotamme välilevyihin ja polyfileihin puuttuvien toimintojen mahdollistamiseksi. Luotamme kirjastoihin nopean kehityksen mahdollistamiseksi ja selän takaamiseksi, kun selainten yhteensopivuus on ongelma.

Puhelimurhaajat, jotka on naamioitu reagoiviksi verkkosivustoiksi. Tweet

'Miksi huolehtia?' saatat kysyä. ”Suurimmalla osalla kävijöistämme on tehokkaat älypuhelimet, joissa on uusimmat käyttöjärjestelmäversiot. He voivat hoitaa sivustojamme. Analytiikka kertoo meille niin. '

Olen pahoillani olki-miehen väitteestä, mutta mielestäni se ansaitsee sanoa ääneen, että ihmiset, jotka voi käyttää sivustoasi on suurin osa käyttäjistäsi. Jos et näe Android 2.3: ta analyysissäsi, tarkoittaakö se, että kyseisillä laitteilla ei ole käyttäjiä? Vai tarkoittaakö se, että sivustollasi ei ole mitään tarjottavaa näille käyttäjille? Ajattele, että monet tämän sukupolven laitteista ovat edelleen hyllyillä, ja niitä ostetaan upouusi myös tänään. Sinun ei pitäisi hylätä sitä suorastaan ​​menneen ajan tekniikkana.

Siksi haluaisin puhua web-kehityksen ihanteellisista tapauksista ja todellisista tavoitteista. Ja käytännöistä ja paradigmista, jotka vievät meidät lähemmäksi noita tavoitteita.

Tiilen ensimmäinen suunnitteluparadigma

Merkittävä osa vuotuisesta puhelinmyynnistä on edelleen ominaisuuspuhelimia. Vielä suurempi osa väestöstä ei osta puhelimia joka vuosi, mutta silti heidän hallussaan on jokin verkkokykyinen laite. Lisää näihin numeroihin viimeisen sukupolven edelleen käytössä olevat älypuhelimet, lisää sytyttimet ja muut puolikykyiset verkkolaitteet (WAP-laitteet, televisiot, leivänpaahtimet, t-paidat ja tiilet). Lisää ne kaikki yhteen ja saatat saavuttaa huikean summan.

Et näe niitä analytiikassa, ellei se toimi siellä. Tweet

Harkitse tämän yleisön käyttötapauksia. He eivät aio lukea pitkiä artikkeleita, selata ja tutkia laitteitaan. Mutta he saattavat kokea kauhuja yrittäessään kirjoittaa URL-osoitteen numeronäppäimistöön ja siirtymällä sivulla suuntanäppäimillä päästäksesi puhelinnumeroon tai tarkistamalla osoitteen lennossa.

Kuinka vaikeaa meidän on sitten ottaa käyttöön mobiililaitteiden ensimmäinen sijoittelu, joka antaa vain nämä tiedot laitteille tietyn kykyjen ja suorituskyvyn kynnyksen alapuolella?

Siro parannus

Hyvällä hajoamisella vähintään parhaana käytäntönä olemme luoneet kaikenkattavan periaatteen, joka (jossain määrin) estää ajattelua sen ulkopuolella. Kun siro hajoaminen on paikallaan, voimme varmasti sanoa, että työmme on tehty ja tehty hyvin. Yhä useammin meidän ei tarvitse edes ajatella sitä, koska eri kehykset ja kirjastot kattavat sen jo. Ja lopuksi polyfillit ja välilevyt poistavat joissakin tapauksissa toiminnallisuuden heikkenemisen tarpeen.

Kun tämä toiminnallisuus tulee yhä helpommin saataville, sen miettimisen tarve (saati sen ylittämisestä) tulee entistä etäisemmäksi.

Tämän artikkelin kannalta se voidaan jakaa seuraavasti:

Armo hajoaminen: Jos ominaisuutta ei ole helposti saatavilla, toteutus epäonnistuu siten, että se muuttuu käyttökelvottomaksi tai käytettäväksi kohtuuttoman epäkäytännöllisellä tavalla.

Siro hajoaminen: Jos ominaisuutta ei ole helposti saatavilla, se epäonnistuu tavalla, joka silti mahdollistaa hyväksyttävän käytettävyyden.

Armoton parannus: Jos ominaisuutta ei ole helposti saatavilla, sitä jäljittelee polyfill-täyttö tai välilevy.

Siellä ongelma ratkaistu.

No, ellet harkitse näiden samojen matalien laitteiden suorituskykyä.

Heiltä puuttuu nuorempien sisarustensa käsittelyteho ja tietokapasiteetti, joten heitä pyydetään kantamaan paljon suurempi kuorma. Polyfillien ottaminen ratkaisuksi luo illuusion siitä, että kaikki modernit toiminnot ovat nyt käytettävissä kaikissa laitteissa ja että niitä voidaan käyttää huoletta.

Ja niin toteutat nykyaikaistaa ja täytä kaikki joka tapauksessa. Vähiten pätevä laite lopulta lataa eniten dataa ja suorittaa eniten käsittelyä. Näin varmistetaan 'paras' loppukäyttäjäkokemus.

Shiv, shim ja polyfill? Luojan kiitos, että useimmat älypuhelimet eivät tue Flashia! Tweet

Ajatus sulavasta parannuksesta kääntäisi ajatuksen aloittamalla alhaisimmilla ominaisuusvaatimuksilla ja lataamalla päivitykset, kunnes suorituskyvyn ja käytettävyyden tasapaino on optimaalinen laitteen ominaisuuksien perusteella. Siten dataliikenne ja käsittelyvaatimukset siirrettäisiin laitteisiin, jotka soveltuvat parhaiten niiden käsittelyyn.

Toki, käsite on tällä hetkellä kohtuuttoman monimutkainen: suurin osa kehyksistä ja kirjastoista ei tue sitä, se on enimmäkseen keskustelematon, ja viittauksia tällaisiin käytäntöihin on vähän, kaukana toisistaan ​​ja paikallisia mikrotoiminnoille. Mutta jossain vaiheessa se oli niin kaikkien käsitteiden ja toimintojen kanssa.

Se voi, mutta onko sen pakko?

Toinen verkkokehityksen paras käytäntö on tarkistaa, onko laitteessa käytettävissä ominaisuus ennen sen aktivointia.

Ota kuitenkin huomioon, että voit asentaa uusimman Google Chrome -version vanhaan Android-puhelimeesi, ja se väittää, että se voi toimia CSS-animaatiot , WebGL , taustaparallaksivaikutukset ja monet muut toiminnot. Mutta se todella, Todella , ei voi. Niin paljon, että selain kaatuu, ja koko laite ei reagoi siihen pisteeseen, että se on käynnistettävä uudelleen hallinnan palauttamiseksi.

Tämä asia on viime aikoina vaikuttanut Android-sovellukset suurella tavalla (käyttäjän näkökulmasta). Yksi merkittävimmistä hajoamisista tässä mielessä on vaikuttanut Google Talk / Hangouts -sovelluksen päivitykseen, joka on muuttanut palvelunsa kevyimmästä käytettävissä olevasta chat-sovelluksesta melkein käyttökelvottomaksi sovellukseksi vanhempien laitteiden suorituskykyongelmien vuoksi. (Korostaakseni tätä seikkaa vielä kerran: 'vanhempi' tarkoittaa tässä, että voit silti ostaa sen hyllyltä, upouuden melkein mistä tahansa kaupasta.) Sama asia vaikutti YouTube-sovellukseen ja Twitter-sovellus (kokemukseni mukaan) ja ilmeisesti monet muut.

Ota siis hetki jossain vaiheessa suunnitteluvaiheesi aikana arvioidaksesi korkean suorituskyvyn ydinominaisuuden arvo huipputehtäviin verrattuna. Tai ainakin jätä sovelluksesi / palvelusi / sisältösi viimeinen sukupolvi jossakin muodossa saataville vanhoille käyttäjille. Siitä puhuen…

Anna käyttäjien kieltäytyä verenvuodon reunasta

Oletko koskaan löytänyt itsesi yrittävän käyttää Gmailia vanhasta laitteesta tai huonon yhteyden kautta? Että Lataa HTML-linkki varmasti tulee kätevä.

Miksi huippuluokan, reagoivassa, animoidussa, kosketuspainotteisessa verkkokaupassasi ei ole tätä toimintoa?

Ajattele sitä: pyysit, että se olisi reagoiva, jotta voit tavoittaa enemmän potentiaalisia asiakkaita. Teit sen kärjessä jättääksesi parhaan ensivaikutelman. Tämän seurauksena vähemmän potentiaalisia asiakkaita voi tavoittaa jopa perustiedot sinusta ja palveluistasi. Jos siro parantaminen on sinulle liian kallis käsite, miksi et ainakaan tarjoa kävijöillesi mahdollisuutta käyttää sisältösi vain tekstiversiota, jos ”WOW” -versio on liikaa heidän laitteilleen.

Tarvitsetko todella koko kirjastoa?

Viimeinen paras käytäntö, jonka haluaisin nähdä siirtyvän hieman standardin ulkopuolelle, on 'käytä tai menetä'. Kirjastojen ja moduulien seuranta ja vain niiden sisällyttäminen on joskus tylsiä, mutta koko työkalupaketin pitäminen jokaisella sivulla on vain huolimaton.

2000-luvun yhteinen valhe: vain muutama sekunti jäljellä. Tweet

Viime aikoina olen seurannut kuinka paljon toimintoja todella käytän, kun sisällytän kirjaston. Ja työkalu, jota käytän useimmin jQuery . Usein huomaan, että olen käyttänyt vain yhtä tai kahta toimintoa (kuten $ .extend tai $ .ready) tai mikä vielä pahempaa, että olen käyttänyt sitä vain saadaksesi elementtejä luokan tai tunnuksen mukaan. Joskus jätän sen niin, toisinaan käyn koodin läpi poistamaan tai irrottamaan riippuvuuden.

Eikö olisikaan siistiä, jos voisit automaattisesti analysoida, mikä ja kuinka suuri osa kirjastosta on käytetty ja laihtunut tulosten perusteella?

Monet kirjastot ja sovellukset tarjoavat mahdollisuuden mukauttaa latausta ennen kuin aloitat sen käytön. Mutta minulla on edelleen tunne, että kirjastojemme automatisoidun 'käytä tai menetä' -rakennusarkkitehtuurin standardointi ei saisi olla liian kaukana ulottuvuudestamme.

Minulla on allergia ”sisällytä kaikki” -lähestymistapaan. Mutta sen käyttö yhdessä tällaisen toiminnallisuuden kanssa saattaa muuttaa lähestymistavan jotain samanlaista kuin prototyyppikortti: liian joustava kehitystyökalu, joka minimoidaan paitsi syntaksissa, myös itse toiminnallisuudessa.

Tarvitaan vain kirjastosta vain kehitysversio, joka mahdollistaisi riippuvan toiminnallisuuden yksikkötestin avulla mahdollisuuden jäljittää käytetyt ominaisuudet ja tuottaa vähimmäisriippuvuuden tai ainakin käyttöasteen (kuten kysyä, olenko sisällyttänyt jQueryn 8 prosenttiin) sen toiminnallisuudesta (80%). Riippuvuustuotantoa voidaan sitten käyttää kirsikoiden valitsemiseen, yhdistämiseen ja tuotannon minimoimiseen.

Mutta mitä voin tehdä asialle?

Ensinnäkin, ota asia mukaan . Ajattele sitä, keskustele siitä ikäisesi kanssa ja yritä havaita asia tosielämän tilanteissa.

Kokeile sitä. Kaivaa viimeisen sukupolven puhelin, jonka olet kätketty jonnekin laatikkoon. Kokeile käyttää sitä omilla verkkosivustoillasi ja tarkista, onko sisältö edes etäkäytettävissä. Mene käymään eräiden aikojen takana olevien sukulaisten luona maassa ja yritä olla heille tekninen evankelista. Katso, helpottavatko heidän esteensä tekniikan käyttöönottoa esteettömyysongelmat.

Jos olet ostaja kun teet verkkosivuston, muista pyytää (ainakin) matalan tason tukea tässä asiassa. Muista: Tavoitteena ei ole luoda täyttä porttia kaikista ominaisuuksistasi matalan tason laitteisiin. Kysytään vain, että nämä käyttäjät saavat yhteystietosi laitteen kaatumisen sijaan.

Varaa varoja tähän: yksinkertaisin ratkaisu ongelmaan ei saisi kestää enemmän kuin päivän tai kaksi ja jonkin verran eteenpäin ajattelua. Pidä mielessä ensisijaiset syyt verkkosivuston tekemiseen (puhumattakaan reagoivan sivuston tekemisestä).

Jos olet pakettikehittäjä työskentelemällä kirjastolla, kehyksellä, paketilla tai muulla upotettavalla ohjelmistolla: sinä pystyt tekemään eniten muutosta täällä. Jos pystyt helpottamaan tai sisällyttämään näitä käsitteitä käyttöympäristösi, sinulla on vaikutusta verkkokehityksen koko maisemaan. Jos sisällytät sen pakettisi suunnitteluun, ilmoita siitä minulle ja minä evankelioin puolestasi.

Ja lopuksi, ** jos olet kehittäjä tai a suunnittelija** , älä pysähdy vain parhaisiin käytäntöihin. Yritä aina katsoa vain vähän sen horisontin yli. Kova työ on sinun työntää näitä käsitteitä, joita kukaan ei vielä ole pyytänyt, joita ei tueta ja joita ei ole dokumentoitu asiakkaiden ja käyttäjien eduksi.

Viime kädessä, jos haluat kuulla jonkun jatkavan tätä tuntikausia ja löytää itsesi lähellä Zagreb , Kerro minulle. Voisimme mennä nappaamaan kupin kahvia.