Устойчивый веб-дизайн - Jeremy Keith Страница 15

Стоит помнить, что создание с прогрессивным улучшением не означает, что все должно быть доступно каждому. Вместо этого важна основная функциональность. Если бы каждая функция должна была быть доступна в каждом браузере на каждом устройстве, это был бы действительно невероятно трудный процесс. Вот почему так важна расстановка приоритетов. Пока основная функциональность доступна с использованием максимально простой технологии, вы можете с чистой совестью добавлять более продвинутые функции.

Тем не менее вполне возможно, что такой подход приведет к дублированию работы. Если вы создадите старомодный клиент-серверный процесс отправки формы, а затем улучшите его с помощью JavaScript, вы можете в конечном итоге повторить обработку формы как на клиенте, так и на сервере. Этого можно избежать, если вы также используете JavaScript на сервере. Теоретически возможно написать универсальный JavaScript, чтобы сервер и браузер использовали единую кодовую базу. Даже без универсального JavaScript я все же думаю, что стоит потратить время на создание технического кредита.

В руководстве по проектированию государственной службы Великобритании приводится еще более краткая форма трехэтапного процесса, который я описал:

Во-первых, просто заставить его работать

Во-вторых, сделать так, чтобы работало лучше

Руководство по проектированию также объясняет, почему:

«Если вы создаете страницы с мыслью о том, что другие части, кроме HTML, являются необязательными, вы создадите более качественную и сильную веб-страницу.»

Такая устойчивость означает, что время, потраченное вами на начальном этапе, будет потрачено с пользой. Вы также можете заметить интересную тенденцию: чем чаще вы используете этот процесс, тем меньше времени он занимает.

Переход от TABLE к CSS казался невозможной идеалистической целью. Дизайнерам было удобно использовать элементы TABLE и FONT для верстки. Зачем им изучать совершенно новый способ работы? Я помню, как сложно было сделать мои первые макеты на основе CSS после многих лет использования хаков. Это заняло у меня довольно много времени. Но мой второй макет на основе CSS не занял так много времени. Через некоторое время это стало обычным делом.

Дизайнерам, привыкшим к макетам с фиксированной шириной, пришлось нелегко с отзывчивым дизайном. Первый гибкий макет неизбежно должен был занять довольно много времени. Но второй гибкий макет занял не так много времени. Через некоторое время это стало обычным делом.

Это не отличается от многоуровневого подхода, необходимого для создания устойчивых веб-сайтов. Если вы не привыкли работать таким образом, то первый раз это займет у вас довольно много времени. Но второй раз уже не займет столько времени. Через некоторое время это станет нормой.

Вполне возможны ситуации, когда трехэтапный подход не сработает, но они не так распространены, как вам кажется. Если вы создаете 3D-игру в веб-браузере, простейшая технология, способная обеспечить основную функциональность, все равно будет довольно сложной. Тем не менее, я бы с удовольствием посмотрел, как приключенческая игра, состоящая только из текста, превращается в шутер от первого лица.

"Как мне убедить…?"

Гениальный ученый-компьютерщик Грейс Хоппер хранила на стене необычные часы. Они шли против часовой стрелки. Когда ее спросили об этом, она ответила, что это произвольная конвенция, сказав:

«У людей аллергия на перемены. Они любят говорить: "Мы всегда делали это так". Я стараюсь бороться с этим. Вот почему у меня на стене висят часы, которые идут против часовой стрелки.»

Коммодор Грейс М. Хоппер, ВМС США.

Изменить поведение сложно. Даже если вы убеждены в преимуществах стойкого подхода к веб-дизайну, вам может быть трудно убедить в этом своих коллег, начальника или клиентов. Так было всегда. Успокойтесь историей веб-стандартов и отзывчивого дизайна. Эти подходы в конечном итоге были приняты людьми, которые изначально сопротивлялись.

Продемонстрировать преимущества прогрессивного улучшения может быть непросто. Поскольку отдача происходит в неожиданных обстоятельствах, многоуровневый подход трудно продать. Большинство людей даже не узнают, был ли сайт создан с использованием прогрессивного улучшения. Это скрытый знак качества, который останется незамеченным людьми с современными браузерами на новых устройствах с быстрым сетевым подключением.

По этой же причине вы можете начать применять этот многоуровневый подход без необходимости убеждать своих коллег, начальника или клиентов. Если им все равно, то они и не заметят. Как сказала Грейс Хоппер, "легче попросить прощения, чем получить разрешение".

Инструменты

Изменение рабочего процесса или процесса может быть особенно сложным, если он вступает в противоречие с используемыми инструментами. Инструмент должен помогать людям выполнять свою работу более эффективно. Инструмент должен быть подчинен рабочему процессу. Слишком часто вместо этого инструменты диктуют предпочтительный способ работы. Будь то редакторы WYSIWYG, программы графического дизайна, системы управления контентом или фреймворки JavaScript, инструменты неизбежно влияют на рабочие процессы.

Если вы осознаете это влияние и сможете его распознать, то у вас будет больше возможностей для выбора инструментов, которые лучше всего подойдут вам. Существует множество факторов, которые влияют на выбор фреймворка, например: "Хорошо ли он написан?", "Есть ли за ним активное сообщество?", "Есть ли у него понятная документация?". Но, возможно, самый важный вопрос: "Соответствует ли его подход моей собственной философии?".

У каждого фреймворка есть своя философия, потому что все фреймворки были написаны людьми. Если ваша философия совпадает с философией фреймворка, то он поможет вам работать более эффективно. Но если ваша философия противоречит философии фреймворка, вы будете бороться с ним на каждом шагу. Может даже возникнуть соблазн просто сдаться и позволить фреймворку диктовать вам рабочий процесс. Тогда хвост будет вилять собакой.

Выбирайте инструменты с умом. Будет очень обидно, если вы откажетесь от гибкого подхода к веб-дизайну из-за разногласий с каким-либо программным обеспечением.

Различия во мнениях часто сводятся к несовпадению приоритетов. В основе подхода прогрессивного улучшения лежит приоритет потребностей людей, независимо от их технологии. Инструменты, фреймворки и библиотеки кода, с другой стороны, часто создаются с учетом приоритета потребностей дизайнеров и разработчиков. В этом нет ничего плохого. Удобство для разработчиков имеет огромную ценность. Но я лично считаю, что потребности пользователей должны превалировать над удобством разработчиков.

Когда я сталкиваюсь с проблемой, и у меня есть выбор: сделать ее проблемой пользователя или моей проблемой, я всегда сделаю ее своей проблемой. Это моя работа.

Дружелюбный к будущему

В сентябре 2011 года я выступал на конференции в Теннесси вместе с несколькими людьми, которые были намного умнее меня. После завершения официального мероприятия мы отправились за