Немного занимаюсь в свободное время frontend-ом (по фану) – CSS3, JavaScript, HTML5, адаптив (чтобы сайт "как игрушка" выглядел, перестраивался динамически под размеры и повороты экрана).
Первым шагом я тестирую полученное на различных разрешениях в эмуляторе Google Chrome с помощью "Device Toolbar".
Когда всё готово, долго и муторно проверяю результат по следующему списку:
Mac OS X:
Google Chrome
Safari 11
TorBrowser
Windows 7, запущенная на VirtualBox под Mac OS X:
Google Chrome
Mozilla Firefox
Opera 45
IE 11
Android 4:
Google Chrome
Android Browser
SimulatorApp 9, запущенный на Mac OS X:
iPhone 4|5|6
iPad 2|Pro|Retina
Интересует опыт профессиональных фронтендщиков:
Насколько оправдан мой список устройств и браузеров для проверки результатов? Вы бы что-нибудь добавили? Что-нибудь выкинули?
Какой workflow у вас? Как проверяете свои наработки? Ведь это целое адище – протестировать свой код в разных браузерах и ОС, отнимает много времени
Ответ
Дисклеймер: я не фронт-энд разработчик, лишь сочувствующий; все выкладки - ИМХО, подкреплённое набитыми шишками.
Шаг первый, подготовительный.
Определите аудиторию сайта, её технические возможности, цель и место посещения. Это позволит примерно понять, в каких условиях люди заходят на сайт и что они от него ждут. Немного примеров навскидку:
Места: из дома, на работе, в транспорте, на детской площадке, в туалете, свисая с моста на страховке, под дождём на автобусной остановке, в зале ожидания в больнице
Устройства вывода: десктоп, ноутбук, планшет, телефон, старый телефон, консоль / телевизор, проектор, слуховой или тактильный аппарат
Устройства ввода: мышь, тачпад, сенсорный экран, мини-пульт, клавиатура, голос
Софт и настройки: навороченный браузер, упрощённый браузер, боковая панелька (Opera <= 12.x, Vivaldi), фрейм в игре (EVE, например)
Обстоятельства: отдых (лениво почитывая или играя), работа (справка, переводчик), активность (про мост и страховку - это не шутка), экстренные случаи, нарушения зрения или координации
Поянтно, что одним сайтом покрыть все варианты невозможно и не нужно; многое зависит от тематики и соотвутствующей целевой аудитории. Исходя из этого можно оценить, какие фичи нужны, а чем можно пренебречь, чтобы облегчить разработку.
Шаг второй, аналитический.
Всё программирование - это поиск золотой середины между усилиями и результатом. Чем-то в любом случае придётся жертвовать (в 2008-м я положил на алтарь свежие плюшки типа jQuery ради нормальной работы в Opera Mini), и в связи с этим по возможности не надо делать лишнего. Собственно, любая новая фича будет требовать поддержки на разных уровнях: изображения, стили, разметка, скрипты, браузерные тесты.
Отсюда два вопроса:
Что требуется от дизайна?
Что от дизайна не требуется?
Постарайтесь максимально формализовать требования к сайту, чтобы их смог понять даже компьютер. Таким требованием может быть "размер гамбургера от 20 до 40 пикселей" или "всплывающее окошко не должно заслонять название элемента", а то и "расстояние от этой ссылки до той кнопки должно уложиться в один свайп по тачпаду". Всё, что такими требованиями не оговорено, будет считаться допустимой погрешностью - и с этим придётся смириться.
Шаг третий, кибернетический.
Автоматизируйте всё.
это целое адище – протестировать свой код в разных браузерах и ОС
Есть сервисы, которые позволяют проверять свои сайты на разных платформах, BrowserStack, например. Все дополнительные фишки платные, но порой хватает и скриншота.
Если подходить более серьёзно - Selenium, есть и обвязки, позволяющие его встроить в юнит-тесты для веб-приложения. Требования с прошлого этапа вполне реально перенести на скрипт и регулярно его запускать. Более того, если есть возможность выделить отдельную машину, Selenium может работать и удалённо, создавая пакеты "логов" на каждый чих.
При наличии автоматизации вопрос проверки в лишнем браузере теряет свою остроту. Сравнение скриноштов позволит увидеть разницу; история изменений - changelog, а видимые косяки перейдут в раздел требований и новых тестов.
Комментариев нет:
Отправить комментарий