Недавно Джеймс Янг расспросил коллег-дизайнеров о самых сложных проблемах, которые приходится решать при разработке адаптивных сайтов. В этой статье он делится результатами исследования и собственными мыслями.
Недавно я проводил опрос: просил коллег- дизайнеров рассказать о трудностях, возникающих при разработке адаптивных сайтов. В этом обзоре собраны самые частые проблемы, возможные способы их решения и полезные рекомендации.
В основе статьи — анализ сотен ответов (если хотите внести свою лепту — исследование ещё продолжается) и мой собственный опыт работы в студии Offroadcode. Итак, не мешкая, перейдём к самым распространённым проблемам адаптивного веб -дизайна и способам их решения.
Хотя об адаптивном дизайне говорят уже больше двух лет, в рамках теории ещё не решены многие вопросы. Дизайнеры работают в среде, где постоянно растёт число устройств, фреймворков и скриптов, кроме того, управление адаптивным проектом подразумевает новые способы взаимодействия с клиентами.
Всё это так или иначе связано с проблемами, указанными респондентами:
«Традиционный» процесс создания сайта представлял собой чёткую последовательность действий и был понятен для клиентов. Сначала составлялся бриф, затем делали схематичные наброски и планировали структуру сайта, наконец, клиенты получали изображения, воспроизводящие интерфейс с точностью до пикселя. Только после их утверждения завершали работу над самим сайтом.
Уверен, многие из вас заметили, что подобный подход больше не работает. Дизайнеры изо всех сил пытаются объяснить клиентам, что «визуальной» стадии больше не существует. Адаптивный дизайн — гораздо более гибкий процесс, и здесь эффективными инструментами становятся каркасные модели, эскизы и прототипы.
Лучший способ рассказать клиенту об адаптивном дизайне — показать его в работе. Рассуждений о стилях разметки (breakpoints), медиазапросах (media queries) и поддержке сайта разными устройствами недостаточно — как бы ни были важны эти вопросы, они не задержатся в памяти клиента надолго.
Отличный результат даёт наглядная демонстрация идеи. Если на встрече с клиентами у вас в распоряжении будут ноутбук, планшет и телефон, с их помощью можно показать работу сайта (например, созданного вами для другого клиента) при разных условиях. Особенно эффективно провести сравнение, продемонстрировав здесь же работу неадаптивного сайта.
Если вы не знаете, какой проект использовать для демонстрации, вам помогут ресурсы, имитирующие самые распространённые стили разметки, например, responsive.is или «Адаптивные разметки адаптивного сайта» (Responsive Layouts, Responsively Wireframed, на иллюстрации выше).
Как я уже писал, многие дизайнеры сетовали на необходимость серьёзных перемен в дизайн- процессе, без которых невозможно использовать все преимущества адаптивного подхода. Вместо подготовки статичных скриншотов, дизайнеры всё чаще полагаются на наброски, блок-схемы, быстрые HTML- и CSS -прототипы, спроектированные «в браузере».
Перед тем, как предложить решение, хочу заметить, что жёстких требований к процессу и порядку работы нет. Я приветствую любые эффективные решения, и если ваш вариант устраивает вас и ваших клиентов — спокойно следуйте отработанному плану.
Как бы то ни было, я предпочитаю по максимуму использовать возможности бумаги и проверять идеи в разном масштабе. Упростить и ускорить работу помогут рекомендации Сэма Хардакра (Sam Hardacre) по созданию эскизов адаптивных сайтов.
Кроме того, я рекомендую как можно раньше начинать «проектирование в браузере» и работу с HTML, а в Fireworks и Photoshop создавать только отдельные графические ресурсы.
Для крупного проекта может потребоваться много каркасных моделей. В этом случае можно воспользоваться идеей Дэна Молла, которую он реализовал в процессе редизайна Crayola.com: сделать набор бумажных каркасных элементов, которые легко передвигать. Этот приём обеспечивают высокую степень гибкости и позволяет скорее получить результат.
Хотите узнать, как организована работа над адаптивными проектами у других дизайнеров — посмотрите презентацию Стивена Хея или подробный обзор студии Yellow Pencil на созданном ими ресурсе responsiveprocess.com.
В прошлом стандартная навигация представляла собой горизонтальную строку наверху или слева внизу страницы. Сейчас при проектировании навигации приходится учитывать очень много факторов. Частое упоминание проблемы респондентами говорит о сложности её решения: готового ответа здесь быть не может.
Навигации очень важна: она влияет на все последующие решения. Определять систему координат надо, исходя их контента и информационной архитектуры сайта, учитывая также ряд дизайн-вопросов. Настоятельно рекомендую перед скачиванием скриптов или демо-версий оценить их работу и замысел, а главное — их пригодность для текущего проекта.
Полезные статьи:
Старайтесь проверять работу навигации на максимальном числе устройств, в разных условиях. Трудно представить, как часто я сталкивался с сайтами, где плохо работала навигация. Не пополняйте этот список.
Как и в случае с навигацией, методы работы с изображениями пока никак не организованы. До сих пор сообщество W3C не разработало спецификации, поэтому мы вынуждены самостоятельно искать решения проблемы и создавать подходящие для устройств графические ресурсы.
Теперь наряду со всем многообразием телефонов, планшетов и настольных компьютеров дизайнеры должны учитывать и устройс тва с высокой плотностью экрана, iPad и Macbook Pro. Их появление сделало задачу ещё сложнее. Как и разметка, изображения и пиктограммы должны быть максимально гибкими, иначе после масштабирования они будут выглядеть размыто.
Пока нет «официального» решения относительно адаптации изображений, стоит попробовать отличные и актуальные способы, которые дают хороший результат без обращения к хакам (hacks) и заплаткам.
Ниже перечислены приёмы и ресурсы по работе с адаптивными изображениями и устройствами с разной пиксельной плотностью:
Заранее снимаю воображаемую шляпу перед воображаемым веб-технологом, который проштудирует все эти ссылки.
Некоторые дизайнеры указывали в качестве проблемы таблицы, особенно со сложной информацией или большим числом столбцов и строк. Втиснуть всё это в маленький экран, сохранив читаемость — сложная задача, и я не уверен, что она вообще решается. Впрочем, ситуация не безнадёжна.
Крис Койер (Chris Coyier) опубликовал в своём блоге обзор удачных идей по работе с таблицами. Как человек, несколько лет проработавший с туристическими сайтами, где часто размещают большие и подробные расписания авиарейсов, должен заметить, что ни один из предложенных вариантов не удовлетворяет требованиям. Однако я уверен, что здесь вы сможете найти если не лучшее решение, то хотя бы идею, от которой можно оттолкнуться.
Несколько приёмов адаптации таблиц:
Пару раз я видел предложения спрятать от пользователей «менее важные данные». Хотя мне нравится экспериментальный характер решения, я категорически против того, чтобы скрывать контент от пользователей каких-либо устройств.
Очень часто упоминалась проблема адаптирования исходного кода старых сайтов с фиксированной шириной. Многие дизайнеры интересовались, стоит ли вообще этим заниматься. Как я уже говорил, процесс адаптивного дизайна отличается от разработки сайта с фиксированной шириной. В последнем случае исполняемый код менее гибок.
Вопрос редизайна сайта сводится к следующему: перерабатывать ли старый шаблон и таблицы стилей или разрабатывать всё с нуля?
Так ответили почти все участники исследования: и те, кто разрабатывал сайты с нуля, и те, кто в силу непреодолимых обстоятельств был вынужден заниматься переработкой старых шаблонов и таблиц стилей.
Разумеется, при создании сайта с фиксированной шириной не учитывали принцип «сначала мобильные» («mobile first») и другие важные способы организации информации. Хотя переписать код и сделать сайт адаптивным возможно, в крупных проектах проще и быстрее сделать всё с нуля.
Уверен, многие из вас ждали критического замечания в адрес Internet Explorer. Действительно, в работе со старыми версиями (IE8 и старше) не было поддержки CSS медиазапросов (CSS media queries). Это означает, что если вы работаете от простого к сложному («mobile first»), например, используете 320 and Up, медиазапросы не будут работать, и ваша разметка не сможет правильно отображаться в десктопном браузере, так что на большом экране пользователи увидят мобильную версию.
Плохая новость заключается в том, что, несмотря на желания дизайнеров (и, надо признать, усилия со стороны Microsoft), они по-прежнему должны учитывать потребности пользователей старых версий (в частности, IE8). Хорошая новость заключается в том, что для поддержки адаптивного дизайна в старых версиях браузера есть несколько эффективных решений.
Если вы намерены твёрдо сохранить разметку сайта в старых версиях IE, не забудьте добавить на страницы полифилл (polyfill) Скотта Джеля — respond.js. Для более глубокого изучения возможностей рекомендую прочитать статью Льюиса Наймана (Lewis Nyman) «Методы работы с отказоустойчивостью медиазапросов» (Techniques For Gracefully Degrading Media Queries).
Если поддержка старых версий браузера вас не беспокоит (был бы контент доступен), тогда лучше не делать ничего. Если вы разрабатывали сайт согласно принципу «сначала мобильные», не используя скрипты вроде respond.js, пользователи старых версий IE могут спокойно работать с мобильной разметкой.
На большом мониторе она будет выглядеть странно, но контент будет доступен. Если это не сработает, стоит подумать об использовании традиционной таблицы стилей для IE и добавить туда простейшие стили (фиксированные размеры), так как лента большинство пользователей не устраивает.
На мой взгляд, ответ на вопрос «Что предложить пользователям старых версий Internet Explorer?» зависит в первую очередь от требований клиента. Я лишь говорю о том, чтобы вы хорошо подумали, прежде чем вычёркивать из списка эту группу пользователей.
В ответах часто затрагивались проблемы тестирования: как и на каких устройствах его проводить, во сколько обойдётся создание тестовой среды (набор устройств)?
Многим дизайнерам, особенно фрилансерам и небольшим студиям, приходится ограничиваться набором личных устройств и тестировать на них — исследование это очень хорошо показало. Часто обходятся тем, что открывают сайт в разных браузерах и меняют пропорции окна, проверяют его работу на своём телефоне и, может быть, планшете. Разумеется, такой вариант далёк от идеала. Набор устройств для тестирования (пусть он будет скромным) — необходимая статья расходов компании.
Многих волнует вопрос о том, сколько времени займёт проверка. Хотя среднее время тестирования возросло, его компенсируют удачные прототипы, «проектирование в браузере», кроме того, отпала необходимость создавать трудоёмкие статичные скриншоты.
Приятно видеть, как крупные агентства, например, Clearleft, делятся своей основательной тестовой базой со всеми, кто приходит в их офис. Хотя такой подход используется редко, уверен, местному творческому сообществу стоит собраться и обсудить инициативу.
Если вам интересно заглянуть в лаборатории других дизайнеров, советую зайти на сайт Стю Робсона (Stu Robson)My Test Suite. Бред Фрост (Brad Frost) написал руководство по тому, как тестировать сайт на реальных устройствах, не рискуя разориться.
Ничто не заменит тестирование на реальных устройствах, но если вы не можете завести арсенал устройств, для начала проверьте работу сайта с помощью любого из доступных инструментов для тестирования адаптивных сайтов, букмарклетов или фреймов. Проверено — помогает.
Спасибо всем моим читателям и участникам опроса. (Если вы ещё не отправили свой ответ, не забудьте сделать это в ближайшее время!) Я с радостью уделю внимание всем проблемам, связанным с развитием адаптивного дизайна и решениям, которые вы используете.
Источник изображения: архив dConstruct archive, автор: Джереми Кейт (Jeremy Keith). Ссылка на оригинал.
Оригинал: http://www.netmagazine.com/features/top-responsive-web-design-problems-and-how-avoid-them
На данный момент технологии и методы, которые применяются при разработке адаптивных сайтов, переживают эру становления с колен на ноги. Что из этого останется и будет претендовать на стандарт, покажет время. Сейчас нет ни у кого точных методов или точного руководства по созданию адаптивного сайта, также на примитивном уровне находятся сами проектные процедуры (прототипы, согласования, презентация заказчику).
Многие понимают, как использовать те или иные инструменты при разработке, но не все умеют ими пользоваться или комбинировать их. У многих за плечами уже есть готовые адаптивные кейсы, но все они пока являются экспериментальным продуктом, требующим большого числа доработок и исправления ошибок. На фоне этого сами заказчики, думаю, еще не все осознали, что их сайт является чем-то передовым и современным, а не обычным сайтом, но только с большим количеством багов.
Данная статья, одна из первых, где автор попытался систематизировать накопленный опыт. На все вопросы статья не отвечает, руководством также не является, но она помогает ответить на вопрос самому себе и указывает на возможные направления, куда желательно двигаться, чтобы быстрее и безболезненно пройти тернистый путь от разработки до сдачи проекта заказчику.
В этой статье собран хороший список частых проблем при разработке адаптивного сайта. Однако часть вопросов не затрагивается. Например, загрузка контента. Ведь для маленькой версии сайта и большой нужен разный объем контента. Стоит ли подгружать его на ходу или изначально определять устройство и отдавать клиенту нужный контент?
Или, например, большие формы и всякие калькуляторы. Они точно не подойдут для маленькой версии. Но как лучше с ними поступить? Особенно если это главное что есть на сайте.
Отдельно меня порадовали решения проблем. Почти все они были с использованием подхода Progressive Enhancement. И ведь правда, этот метод как нельзя лучше подходит при разработке адаптивных сайтов.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Digital Creative Director Leo Burnett Group Russia
Наши клиенты в ближайшие лет пять с таким подходом точно не смогут смириться, учтите это. Я не консерватор, я хорошо понимаю, о чем пишет автор, просто я реалист. У нас еще веб-дизайнеры-то далеко не все знают, что это такое, а что уж говорить про клиентов.