Дієта з ванільного павутиння - розгромний журнал
Розгромна розсилка
Щотижня ми надсилаємо корисні інтерфейсні та UX-методи. Підпишіться та отримайте Контрольні списки розумного дизайну інтерфейсу PDF доставляється у вашу поштову скриньку.
Примітка редактора: Це вступна стаття про книжкова ідея опублікувати журнал Smashing Magazine разом із Крісом Хайльманом. Перевірте, що ми пропонуємо як ідею, - пояснивши спосіб переглянути спосіб побудови веб-сайтів, щоб переконатися, що вони є більш стрункими та надійними для майбутнього. В кінці статті ми попросимо вас заповнити коротке опитування, щоб продемонструвати свій інтерес.
Зараз Інтернет страждає від проблеми ожиріння. Якщо ви займаєтеся серфінгом Інтернету через нестійкий мобільний зв’язок чи якийсь готельний бездротовий зв’язок, ви неодноразово опиняєтесь, дивлячись на сторінку чи програму, яка нічого не робить і не повідомляє вам, що відбувається. Спінер на вкладці або в рядку URL-адреси здається тим, що отримує найбільший пробіг у браузерах. Серфінг із відкритою вкладкою в інструментах розробника показує неймовірний обсяг даних, що надсилаються для, здавалося б, дуже простих кінцевих продуктів.
Чому так? Хіба роки веб-розробки та пропаганди ефективності роботи Yahoo, Google та багатьох інших не мали плодів і дали нам зрозуміти, скільки коштує кожен запит HTTP? Якщо дивитись на кінцеву продукцію, то це не здається таким чином.
Причини для ожиріння
Є кілька причин, чому наш Інтернет знаходиться на пухкій стороні, і більшість із них насправді можна змінити нам як розробникам.
Ми не розвиваємося в реалістичних середовищах
Ймовірно, головна причина полягає в тому, що ми, як розробники, працюємо на швидких і великих комп'ютерах, підключених до жирової лінії, і вперше хтось тестує нашу продукцію на повільних з'єднаннях під час забезпечення якості (QA). І оскільки якісний контроль - це перше, що потрібно втратити, коли терміни не дотримуються, іноді цього взагалі ніколи не відбувається.
Вчепившись у минуле
Ще однією причиною любовної поведінки в наших веб-продуктах є помилкове почуття вірності застарілим і старим технологіям, а саме браузерам 90-х, які відмовляються піти. Існує багато спроб вирішити проблему застарілих середовищ, кожна з яких має свої проблеми. Справа в тому, що на надзвичайно застарілих комп’ютерах є дуже багато кінцевих користувачів з поганими браузерами та, ймовірно, обмеженими зв’язками. Цих користувачів не слід блокувати, але вони також не повинні диктувати, що ми будуємо.
Відмінності браузера
Ще однією великою причиною є роздратування у відмінностях браузера. Існує не так багато веб-технологій та API, де всі браузери погоджуються, коли йдеться про їх підтримку, і багато разів нам потрібно повторити код і форк і протестувати, щоб надати однакові функції всім.
Охоплюючи хаос та відзначаючи відмінності
Останній пункт - це головна помилка, яку ми робимо: замість того, щоб сприймати хаос, який є Інтернет, а також середовище та можливості наших кінцевих користувачів, ми, здається, не можемо відмовитись від мрії про наявність продукту, який працює та виглядає скрізь однаково.
Мій браузер - це не світ?
У гіршому випадку ми намагаємось досягти цього, блокуючи всі браузери, які нам не подобаються, і з гордістю проголошуючи, що "всі користуються браузером X, а хто не - ворогом сучасної мережі". Це, звичайно, просто бреше нам самим і базується на швидкоплинній концепції "сучасної мережі". Багато найстрашніших веб-продуктів, що існували там, були побудовані роки тому, щоб працювати лише в Internet Explorer (IE) 6, який на той час був бджолиним коліном. Немає значення, в якому крутому обладнанні є гарячий провідний браузер, який зараз гарячий - ми знову робимо ту ж помилку, якщо створюємо лише один браузер, а інші блокуємо.
Блокування будь-якого браузера означає фактичне написання додаткового коду для тестування браузерів, і майже неможливо достовірно визначити, який браузер використовується. Якщо вам потрібні докази, просто швидко перегляньте рядок агента користувача браузера Яндекс, який містить імена майже всіх механізмів браузера:
_Mozilla/5.0 (Macintosh; Intel Mac OS X 10_82) AppleWebKit/536.5 (KHTML, як Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5
Я сподіваюся, що ми можемо домовитись, що створення одного браузера (або движка) працює для вас, лише якщо ви націлені на певний ринок і групу, і навіть тоді ви не застраховані від їх втрати найближчим часом.
Бібліотеки - це майбутнє
Ще одна спроба досягти мрії про одноманітність між браузерами - це стратегія абстрагування, що використовує бібліотеки, полізаповнення та фреймворки, щоб ми могли писати на одній мові, а вся магія різниці в браузері відбувалася під капотом. Для виробничого використання це дуже гарна ідея. Зрештою, бібліотеки повинні доставити нас туди, куди ми хочемо бути - майже кожне програмне середовище, рано чи пізно, працює за допомогою бібліотек, які уніфікують доступ до апаратного забезпечення або API даних. Для розробки додатків нам потрібно визначити та розвивати ці бібліотеки та використовувати їх на свою користь.
Вбудований резерв
Проблема, яку ми маємо зараз, полягає в тому, що бібліотеки та фреймворки абстракції стають відправною точкою, і у випадку простих веб-сайтів із трохи зайвого чуття вони не потрібні. Ми просто почали використовувати їх, не враховуючи їхнього впливу, або навіть забули, як це робити без них. І в багатьох випадках багато речей, які ми робимо з ними, вже доступні у браузері для нас, нам просто потрібно використовувати те, що є, замість того, щоб імітувати це. Самі бібліотеки починають страждати ожирінням, і у багатьох випадках додатковий жир - це функція, яка змушує застарілі браузери робити те, чого вони ніколи не мали, але що браузери на основі специфікації HTML5 вже вбудовані.
Смерть тисячею плагінів
Зловживання абстракцією коду в ці часи поширюється. Ми використовуємо бібліотеки та конвертери, які дозволяють нам писати найменшу кількість коду, щоб досягти великої кількості. Це пов’язано з ціною. Три рядки, які ми пишемо абстрактною мовою, можуть перетворитися на десятки після перетворення на зрозумілий для браузера код. Дуже спокусливо використовувати 20 невеликих скриптів на наших сторінках, коли всі вони складають лише кілька рядків, але це становить масу HTTP-запитів та генерованого коду, який задихає браузер. Оскільки ми ніколи не бачимо цей код, це, здається, не є нашою помилкою - ми просто написали найменшу кількість коду. Безумовно, додавання ще одного сценарію з лише п’ятьма рядками коду не може змінити ситуацію?