Veebi Kasutajaliides
Tundlikust kujundusest ei piisa, vajame reageerivat jõudlust
Viimasel ajal olen kokku puutunud paljude asjadega tundlikud veebisaidid koos palju jõudlusprobleeme. Enamikul neist on probleemid nii ilmsed, et peale uusima põlvkonna nutitelefonide on need peaaegu kasutud. Arvestades asjaolu, et reageerimisvõime kui mõiste on mõeldud jõudma a laiem publikule tundub see pigem kahjulik.
Suurim panus selles küsimuses on endiselt levinud töölauale esmase kujunduse paradigma. Kõigepealt näib, et mõeldes mobiiltelefoni perspektiivist, kuid see üksi ei taga rahuldavat jõudlust. Tundub, et me kõik loodame liialt enam-vähem graatsilisele degradeerumisele. Puuduva funktsionaalsuse võimaldamiseks loodame aluskatetele ja polüfillidele. Kiire arengu võimaldamiseks ja selja tagamiseks tugineme raamatukogudele, kui brauseri ühilduvus on probleem.
Telefonimõrvarid vabas õhus, varjatuna reageerivateks veebisaitideks. Piiksuma
'Milleks muretseda?' võite küsida. 'Enamikul meie külastajatel on suure jõudlusega nutitelefonid, millel on nende uusimad OS-i versioonid. Nad saavad meie saitidega hakkama. Analüütika ütleb meile seda. '
Mul on õlekõrremeeste pärast kahju, kuid arvan, et see väärib valjusti väljaütlemist, et inimesed, kes saab teie saidi kasutamine on enamus teie kasutajatest. Kui te ei näe oma analüüsides Android 2.3, kas see tähendab, et nende seadmetega pole ühtegi kasutajat? Või tähendab see, et teie saidil pole neile kasutajatele midagi pakkuda? Mõelge, et paljud selle põlvkonna seadmed on endiselt riiulitel ja neid ostetakse tänapäevalgi uhiuusena. Te ei tohiks seda otsekohe tagasi lükata kui eelmise aasta tehnoloogiat.
Seetõttu tahaksin rääkida veebiarenduse ideaaljuhtudest ja tegelikest eesmärkidest. Ja tavadest ja paradigmadest, mis lähendavad meid neile eesmärkidele.
Tellistest esimene kujundusparadigma
Märkimisväärse osa aastamüügist võtavad endiselt telefonid. Veelgi suurem osa elanikkonnast ei osta igal aastal telefone, kuid siiski on nende käsutuses mõni veebivõimeline seade. Lisage neile numbritele veel kasutuses olevad viimase põlvkonna nutitelefonid, lisage Kindles ja muud pooleldi veebi võimaldavad seadmed (WAP-seadmed, telerid, rösterid, t-särgid ja tellised). Kui lisate need kõik kokku, võite jõuda vapustava summani.
Mõelge selle vaatajaskonna kasutamisjuhtudele. Nad ei hakka pikki artikleid lugema, oma seadmetes sirvima ja uurima. Kuid nad võivad läbida õudusi, kui nad proovivad numbriklaviatuuril sisestada URL-i ja navigeerida lehel suunaklahvide abil, et telefoninumbrini jõuda, või kontrollida aadressi käigu pealt.
Kui raske on meil siis rakendada mobiilseadmete esmane paigutus, mis pakub seadmetele ainult teatud teavet, mis jääb alla teatud võimete ja jõudluse künnise?
Graatsiline täiustamine
Kuna graatsiline degradeerumine on minimaalne parim tava, oleme loonud kõikehõlmava põhimõtte, mis takistab (mingil määral) sellest kaugemale mõtlemist. Kui graatsiline degradeerumine on paigas, võime kindlasti öelda, et meie töö on tehtud ja hästi tehtud. Üha sagedamini ei pea me sellele isegi mõtlema, kuna seda juba hõlmavad erinevad kasutatavad raamistikud ja teegid. Lõpuks eemaldavad polüfillid ja alused mõnel juhul täielikult funktsionaalsuse halvenemise vajaduse.
Kui see funktsionaalsus muutub üha hõlpsamini kättesaadavaks, muutub vajadus selle üle järele mõelda (rääkimata sellest kaugemale) üha kaugemale.
Selle artikli seisukohast võiks selle jaotada järgmiselt:
Graatsiline alandamine: Kui funktsioon pole hõlpsasti kättesaadav, ebaõnnestub juurutamine nii, et see muutub kasutuskõlbmatuks või kasutatavaks liiga ebapraktilisel viisil.
Graatsiline degradeerumine: Kui funktsioon pole hõlpsasti saadaval, siis see ebaõnnestub viisil, mis võimaldab siiski vastuvõetavat kasutatavust.
Graatsiline paranemine: Kui see funktsioon pole hõlpsasti kättesaadav, jäljendab see polüfilli või aluspinda.
Seal on probleem lahendatud.
Noh, kui te ei arvesta nende samade odavate seadmete jõudlust.
Kuna neil pole oma nooremate õdede-vendade töötlemisvõimsust ja andmesidevõimalusi, palutakse neil kanda palju suuremat koormust. Polüfillide võtmine lahendusena loob illusiooni, et kõik kaasaegsed funktsioonid on nüüd kõigis seadmetes saadaval ja neid saab muretult kasutada.
Ja nii te rakendate kaasajastama ja täitke igaks juhuks kõik. Kõige vähem pädev seade laadib lõpuks kõige suurema hulga andmeid ja töötleb kõige rohkem. Nii tagatakse 'parim' lõppkasutaja kogemus.
Graatsilise täiustamise idee muudaks kontseptsiooni, alustades madalaimatest funktsiooninõuetest ja laadides versiooniuuendusi, kuni jõudluse ja kasutatavuse tasakaal on seadme võimaluste põhjal optimaalne. Seega liigutataks andmeliiklus- ja töötlemisnõuded seadmetesse, mis nende töötlemiseks kõige paremini sobivad.
Muidugi on see kontseptsioon praegu ülemäära keeruline: seda ei toeta enamus raamistikke ja raamatukogud, enamasti pole seda arutatud ja viiteid sellistele tavadele on vähe, kaugel ja lokaliseeritud mikrofunktsionaalsustele. Kuid mingil hetkel oli see kõigi mõistete ja funktsionaalsustega nii.
Võib, aga kas peabki?
Teine veebiarenduse parim tava on kontrollida, kas seade on enne selle aktiveerimist funktsioon saadaval.
Kuid arvestage sellega, et saate oma vanale Android-telefonile installida Google Chrome'i uusima versiooni ja see väidab, et see võib töötada CSS-i animatsioonid , WebGL , taustaparallaksi efektid ja paljud muud funktsioonid. Aga tõesti, tõesti , ei saa. Nii palju, et brauser jookseb kokku ja kogu seade ei reageeri hetkeni, mil juhtimise taastamiseks tuleb see taaskäivitada.
See probleem on viimasel ajal hakanud mõjutama Androidi rakendused suures plaanis (kasutaja seisukohast). Üks selles mõttes kõige märgatavam halvenemine on mõjutanud Google Talki / Hangoutsi rakenduse täiendamist, mis on vanemate seadmete jõudlusprobleemide tõttu muutnud nende teenuse kõige kergemast vestlusrakendusest peaaegu kasutuskõlbmatuks rakenduseks. (Selle asja veel kord rõhutamiseks: “vanem” tähendab siin seda, et saate seda ikkagi osta riiulilt, uhiuusena peaaegu igas poes). Sama teema mõjutas YouTube'i rakendust ja Twitteri rakendus (minu kogemuse järgi) ja ilmselt paljud teised.
Niisiis, võtke oma planeerimisetapil üks hetk aega, et hinnata suure jõudlusega põhifunktsiooni väärtust tipptasemel meigi suhtes. Või vähemalt jätke oma rakenduse / teenuse / sisu viimane põlvkond pärandkasutajatele mingil kujul kättesaadavaks. Millest rääkides…
Laske kasutajatel verejooksu servast loobuda
Kas olete kunagi leidnud, et proovite Gmaili kasutada vanast seadmest või kehva ühenduse kaudu? Seda Link HTML-i laadimiseks kindlasti tuleb kasuks.
Miks pole teie tipptasemel, tundlikul, animeeritud ja puutetundlikul veebipoel seda funktsionaalsust?
Mõelge sellele: palusite, et see oleks reageeriv, et jõuaksite rohkemate potentsiaalsete klientideni. Parima esmamulje jätmiseks tegite selle tipptasemel. Selle tulemusena jõuavad vähem potentsiaalsed kliendid isegi teie ja teie teenuste põhiteabe juurde. Kui graatsiline täiustamine on teie jaoks liiga kulukas mõiste, siis miks te ei paku vähemalt oma külastajatele võimalust pääseda juurde oma sisu ainult tekstiversioonile, kui “WOW” versioon on nende seadmete jaoks liiga palju.
Kas vajate tõesti kogu raamatukogu?
Lõpuks on viimane parim tava, mida tahaksin standardist pisut kaugemale tõsta, see “kasuta või kaota”. Jälgida, milliseid teeke ja mooduleid tegelikult kasutatakse, ja lisada ainult neid, on mõnikord tüütu, kuid kogu tööriistakomplekti igal lehel hoidmine on lihtsalt lohakas.
Hiljuti olen jälginud, kui palju funktsioone ma tegelikult kasutan, kui lisan teegi. Ja tööriist, mida ma kõige sagedamini kasutan jQuery . Tihti leian, et olen kasutanud vaid ühte või kahte funktsiooni (näiteks $ .extend või $ .ready) või veelgi hullem, et olen seda kasutanud lihtsalt elementide saamiseks klassi või ID järgi. Mõnikord jätan selle nii, teinekord lähen koodi uuesti läbi, et sõltuvus eemaldada või lahutada.
Kas poleks puhas, kui saaksite tulemuste põhjal automaatselt analüüsida, mida ja kui palju raamatukogu on lõpuks kasutatud ja kaalust alla võetud?
Paljud raamatukogud ja rakendused pakuvad võimalust enne väljalaadimist enne selle kasutamist kohandada. Kuid mul on jätkuvalt tunne, et automatiseeritud 'kasuta või kaota' ehituskonstruktsiooni standardimine meie raamatukogudes ei tohiks olla meie käeulatusest kaugel.
Mul on allergia lähenemise „sisalda kõike“ suhtes. Kuid selle kasutamine koos sellise funktsionaalsusega võib muuta lähenemise prototüüpimisplaadile sarnaseks: liiga paindlikuks arendustööriistaks, mis minimeeritakse mitte ainult süntaksis, vaid ka tegelikus funktsionaalsuses.
Vaja oleks ainult teegi arendusversiooni, mis võimaldaks sõltuva funktsionaalsuse üksustesti abil tuvastada kasutatud funktsioone ja väljastada minimaalse sõltuvuse või vähemalt kasutuskaala (näiteks küsimine, kas ma lisan jQuery 8% -le või 80%). Sõltuvuse väljundit võiks siis kasutada toodangu tootmiseks kirsside valimiseks, liitmiseks ja minimeerimiseks.
Aga mida ma saan sellega teha?
Esiteks, tegeleda küsimusega . Mõelge sellele, arutage seda oma eakaaslastega ja proovige probleemi reaalsetes stsenaariumides märgata.
Proovi. Kaevake välja see viimase põlvkonna telefon, mille olete kuhugi sahtlisse peitnud. Proovige seda oma veebisaitidel kasutada ja kontrollige, kas sisu on isegi kaugkasutatav. Minge külastage mõnda maal elavat sugulast ja proovige olla neile tehnoloogiaevangelist. Vaadake, kas ligipääsetavuse probleemid hõlbustavad nende viivitust tehnoloogia kasutuselevõtmisel.
Kui olete ostja Veebisaidi tellimisel küsige selles küsimuses kindlasti (vähemalt) madalat tuge. Pidage meeles: eesmärk ei ole luua kõigi oma funktsioonide täielikku porti madalate seadmetega. Palutakse vaid, et need kasutajad saaksid teie seadme krahhi asemel teie kontaktandmed.
Eraldage selleks tegelikud ressursid: küsimuse lihtsaim lahendus ei tohiks kesta kauem kui päev või paar ja veidi edasi mõelda. Pidage meeles kõige põhilisemaid põhjuseid veebisaidi loomiseks (rääkimata tundliku saidi loomisest).
Kui olete pakettide arendaja töötamine raamatukogu, raamistiku, komplekti või mõne muu manustatava tarkvara kallal: teie olete see, kes saab siin kõige paremini hakkama saada. Kui saate neid mõisteid hõlbustada või oma platvormi lisada, mõjutate kogu veebiarenduse maastikku. Kui lisate selle oma pakendikujundusse, andke mulle teada ja ma evangeelsen teie eest.
Ja lõpuks, ** kui olete arendaja või a disainer ** , ärge peatuge ainult parimate tavade juures. Püüa alati vaadata vaid veidi üle selle silmapiiri. Teil on raske töö nende mõistete väljatöötamiseks, mida keegi veel ei küsinud, mida teie kliendid ja kasutajad ei toeta ja dokumentideta.
Lõppkokkuvõttes, kui soovite, et keegi tunniks seda tundide kaupa ja leiaks end lähedal Zagreb , Anna mulle teada. Võiksime minna tassi kohvi haarama.
