Напоследък се сблъсквам с много отзивчиви уебсайтове с много на проблеми с изпълнението. При повечето от тях проблемите са толкова очевидни, че са почти безполезни за нищо освен най-новото поколение смартфони. Предвид факта, че отзивчивост тъй като концепцията има за цел да достигне до по-широк аудитория, това изглежда доста контрапродуктивно.

Най-големият принос за този брой е все още преобладаващата парадигма за дизайн на десктоп. Мисленето от гледна точка на mobile-first изглежда засяга проблема, но само това не гарантира задоволителна производителност. Изглежда, че всички разчитаме твърде много на повече или по-малко грациозна деградация. Разчитаме на подложки и полифилове, за да дадем възможност за липсваща функционалност. Разчитаме на библиотеките, за да дадем възможност за бързо развитие и да се подкрепим, когато съвместимостта на браузъра е проблем.

Телефонни убийци на свобода, маскирани като отзивчиви уебсайтове. Tweet

'Защо се притесняваш?' може да попитате. „Повечето от нашите посетители имат високоефективни смартфони с най-новите версии на операционната система. Те могат да се справят с нашите сайтове. Анализът ни казва така. '

Съжалявам за аргумента на сламения човек, но мисля, че заслужава да се заяви на глас, че хората, които мога използвайте вашия сайт ще бъде по-голямата част от вашите потребители. Ако не виждате Android 2.3 в анализа си, означава ли това, че няма потребители с тези устройства? Или означава, че вашият сайт няма какво да предложи на тези потребители? Помислете, че много устройства от това поколение все още са на рафтовете и се купуват чисто нови дори днес. Не бива да го отхвърляте направо като технология от миналото.

Затова бих искал да говоря за идеалните случаи и действителните цели на уеб разработката. И за практики и парадигми, които ни доближават до тези цели.

Първа тухлена парадигма на дизайна

Значителна част от годишните продажби на телефони все още се поемат от функционални телефони. Още по-голяма част от населението не купува телефони всяка година, но въпреки това разполага с някакво устройство с възможност за уеб. Добавете към тези номера смартфони от последно поколение, които все още се използват, добавете устройствата за запалване и други полу-съвместими устройства (WAP устройства, телевизори, тостери, тениски и тухли). Съберете ги всички и може да достигнете зашеметяваща сума.

Няма да ги видите в анализа си, освен ако не работи там. Tweet

Помислете за случаите на използване за тази аудитория. Те няма да четат дълги статии, да разглеждат и изследват на своите устройства. Но те могат да преживеят ужасите при опит да въведат URL адрес на цифровата клавиатура и да навигират в страницата с помощта на клавиши за насочване, за да стигнат до телефонен номер или да проверят два пъти адрес в движение.

Колко трудно е тогава за нас да приложим подмобилно първо оформление, което ще предоставя само тази информация на устройствата под определен праг на възможности и производителност?

Грациозно подобрение

С грациозната деградация като минимална най-добра практика, ние създадохме общ принцип, който (до известна степен) пречи на мисленето отвъд него. След като настъпи грациозната деградация, със сигурност можем да кажем, че нашата работа е свършена и е свършена добре. Все по-често дори не трябва да мислим за това, тъй като той вече е обхванат от различните използвани рамки и библиотеки. И накрая полифиловете и подложките напълно премахват необходимостта от влошаване на функционалността в някои случаи.

Тъй като тази функционалност става все по-лесно достъпна, необходимостта да се мисли за нея (камо ли извън нея) става все по-отдалечена.

От гледна точка на тази статия тя може да бъде разделена по следния начин:

Неблагодарна деградация: Ако дадена функция не е лесно достъпна, изпълнението се проваля по такъв начин, че става неизползваем или използваем по прекалено непрактичен начин.

Грациозно разграждане: Ако дадена функция не е лесно достъпна, тя се проваля по начин, който все още позволява приемлива използваемост.

Неблагодарно подобрение: Ако функцията не е лесно достъпна, тя се емулира от полифил или подложка.

Там проблемът е решен.

Е, освен ако не вземете предвид производителността на същите тези устройства от нисък клас.

Липсвайки процесорната мощ и възможностите за данни на техните по-малки братя и сестри, те са помолени да носят много по-голямо натоварване. Приемането на полифилове като решение създава илюзия, че всички съвременни функционалности вече са достъпни на всички устройства и могат да се използват без притеснение.

И така прилагате модернизирам и полирайте всичко за всеки случай. Най-малко компетентното устройство в крайна сметка зарежда най-голямо количество данни и извършва най-голямо количество обработка. По този начин се гарантира „най-доброто“ изживяване на крайния потребител.

Shiv, shim и polyfill? Слава богу, повечето смартфони не поддържат Flash! Tweet

Идеята за изящно подобрение би обърнала концепцията, като започне с най-ниските изисквания за функции и зарежда надстройки, докато балансът между ефективността и използваемостта не бъде оптимален въз основа на възможностите на устройството. По този начин изискванията за трафик на данни и обработка ще бъдат преместени към устройствата, най-подходящи за тяхното обработване.

Разбира се, в момента концепцията е прекалено сложна: тя не се поддържа от повечето рамки и библиотеки, най-вече не се обсъжда и препратките към такива практики са малко, отдалечени и локализирани на микрофункционалности. Но в някакъв момент беше така с всички концепции и функционалности.

Може, но трябва ли?

Друга най-добра практика при уеб разработката е проверка дали дадена функция е налична на устройство, преди да я активирате.

Вземете предвид обаче, че можете да инсталирате най-новата версия на Google Chrome на вашия годишен телефон с Android и той ще твърди, че може да работи CSS анимации , WebGL , фонови паралакс ефекти и много други функционалности. Но наистина, наистина ли , не може. Дотолкова, че браузърът ще се срине и цялото устройство ще реагира до такава степен, че ще трябва да се рестартира, за да си възвърне контрола.

Този проблем напоследък започна да засяга Приложения за Android в голяма степен (от гледна точка на потребителя). Една от най-забележимите деградации в този смисъл се отрази на надстройката на приложението Google Talk / Hangouts, която превърна тяхната услуга от най-лекото приложение за чат на разположение в почти неизползваемо приложение поради проблеми с производителността на по-стари устройства. (Само за да подчертая този момент още веднъж: „по-старо“ тук означава, че все още можете да го купите готово, чисто ново в почти всеки магазин). Същият въпрос засяга приложението YouTube и приложението Twitter (според моя опит) и очевидно много други.

Така че, отделете малко време по време на фазата на планиране, за да оцените стойността на основната характеристика с висока производителност над модерния грим. Или поне оставете последното поколение на вашето приложение / услуга / съдържание на разположение под някаква форма за наследените потребители. Говорейки за това ...

Нека потребителите се откажат от Bleeding Edge

Случвало ли ви се е да се опитвате да използвате Gmail от старо устройство или чрез лоша връзка? Че Връзка „зареждане на основен HTML“ със сигурност е полезен.

Защо вашият авангарден, отзивчив, анимиран, ориентиран към докосване онлайн магазин не разполага с тази функционалност?

Помислете за това: поискахте да реагира, за да можете да достигнете до повече потенциални клиенти. Направихте го режещо, за да оставите най-доброто първо впечатление. В резултат на това по-малко потенциални клиенти могат да достигнат дори основната информация за вас и вашите услуги. Ако изящното подобрение е твърде скъпо понятие за вас, защо поне не предложите на посетителите си опцията за достъп до текстова версия на вашето съдържание, ако Версия “WOW” е твърде много за техните устройства.

Наистина ли ви е необходима цялата библиотека?

И накрая, последната най-добра практика, която бих искал да видя, изтласкана малко над стандартното, е „използвай го или го загуби“. Да следите кои библиотеки и модули всъщност се използват и да включвате само тях, понякога е досадно, но запазването на целия ви набор от инструменти на всяка страница е просто небрежно.

Обща лъжа на 21 век: остават само няколко секунди. Tweet

Наскоро взех да следя колко функционалност всъщност използвам, след като включа библиотека. А инструментът, който използвам най-често, е jQuery . Често откривам, че съм използвал само една или две функционалности (като $ .extend или $ .ready) или дори по-лошо, че съм го използвал само за да получа елементи по клас или ID. Понякога го оставям така, друг път се връщам през кода, за да премахна или отделя зависимостта.

Не би ли било добре, ако можете автоматично да анализирате какво и колко от библиотеката в крайна сметка се използва и губи тегло въз основа на резултатите?

Много библиотеки и приложения предлагат опцията за персонализиране на зареждането, преди да започнете да го използвате. Но продължавам да чувствам, че не би трябвало да е твърде далеч от обсега ни, за да стандартизираме автоматизираната архитектура за изграждане „използвай или загуби“ в нашите библиотеки.

Имам алергия към подхода „включвам всичко“. Но използването му заедно с такава функционалност може да превърне подхода към нещо подобно на прототипираща дъска: прекалено гъвкав инструмент за разработка, който се минимизира не само в синтаксиса, но и в самата функционалност.

Това, което би се изисквало, е само версия за разработка на библиотеката, която чрез единичен тест на зависима функционалност ще позволи проследяване на използваните функции и извеждане на минималната зависимост или поне мащаб на използване (като например дали съм включил jQuery за 8% от неговата функционалност или 80%). След това изходът на зависимостта може да се използва за бране на череши, агрегиране и минимизиране на продукцията за производство.

Но какво мога да направя за това?

Преди всичко, ангажирайте проблема . Помислете за това, обсъдете го с връстниците си и се опитайте да забележите проблема в реални сценарии.

Опитай го. Изровете онзи телефон от последно поколение, който сте прибрали някъде в чекмеджето. Опитайте да го използвате на собствените си уебсайтове и проверете дали съдържанието е дори дистанционно използваемо. Посетете някои роднини в страната и се опитайте да им бъдете технически евангелизатор. Вижте дали изоставането им в технологичното усвояване всъщност се улеснява от проблемите с достъпността.

Ако сте купувач въвеждане на уебсайт в експлоатация, не забравяйте да поискате (поне) поддръжка на ниско ниво по този въпрос. Запомнете: целта не е да създадете пълен порт на всичките си функции към устройства с ниско ниво. Всичко, което се иска, е тези потребители да получат информацията ви за контакт, вместо устройството им да се срине.

Заделете действителни ресурси за това: най-простото решение на проблема не трябва да отнема повече от ден-два и известно мислене напред. Имайте предвид най-основните причини за създаването на уебсайта на първо място (да не говорим за създаването на реагиращ сайт).

Ако сте разработчик на пакети работа върху библиотека, рамка, пакет или друг вграден софтуер: вие сте този, който може да направи най-голямото значение тук. Ако можете да улесните или да включите тези концепции във вашата платформа, ще повлияете на целия пейзаж на уеб разработката. Ако го включите в своя дизайн на опаковката, уведомете ме и ще ви благовестя.

И накрая, ** ако сте разработчик или а дизайнер ** , не се спирайте само на най-добрите практики. Винаги се опитвайте да гледате малко над този хоризонт. Усилната работа е върху вас да прокарате тези концепции, които още никой не е поискал, които не се поддържат и не са документирани в полза на вашите клиенти и потребители.

В крайна сметка, ако искате да чуете някой да продължава с това с часове и да се озовете наблизо Загреб , кажи ми. Можем да отидем да вземем чаша кафе.