Frontender Magazine

Разработка дизайна по контрольным точкам

Примечание редактора A List Apart: Мы рады представить вам фрагмент главы 7 новой книги Стивена Хэя (Stephen Hay) «Рабочий процесс проектирования отзывчивого дизайна» (Responsive Design Workflow), доступной уже сейчас, благодаря издательству New Riders.

Согласно утверждению Джереми Кита (Jeremy Keith) то, что происходит с представлением между контрольными точками, так же важно, как и сами контрольные точки — и, пожалуй, даже важнее. Я с этим согласен, и давайте разберемся, почему. В некотором смысле эта часть процесса напоминает мне раскадровку или создание ключевых кадров анимации, в то время, как промежуточные кадры разрабатываются позднее. Этим мы и займемся

Основные контрольные точки — это условия, при которых происходят ключевые изменения в вашем макете. Такой точкой может быть, например, значение, при котором ваш макет из двухколоночного становится четырехколоночным.

Допустим, из ваших набросков вы выбрали 3 основных направления дизайна. Подумайте, как будет выглядеть макет в основных контрольных точках (Рисунок 7.6). И вот что еще важно: постарайтесь выбрать как можно меньше контрольных точек. Это может звучать странно, ведь мы говорим об отзывчивом дизайне. В конце концов, у нас же есть медиа-выражения, давайте использовать 12 точек, так? Нет! Если линейное последовательное расположение элементов подходит для всех типов экранов и соответствует вашей концепции, нет необходимости разрабатывать другие схемы расположения элементов. В этом случае просто опишите, что должно произойти при увеличении размера экрана. Останется ли все, за исключением размера шрифта, межстрочного расстояния и отступов, в том же виде? Если так, сделайте эскиз с учетом этих изменений, изучите варианты, а затем переходите к более проработанным прототипам. Используйте подготовленный вами список контрольных точек и разрабатывайте эскизы в соответствии с ним.

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

Грубые эскизы дизайна на основных контрольных точках помогут вам определить:

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

Рисунок 7.6

Рисунок 7.6: Большинству сайтов требуется гораздо меньше контрольных точек.

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

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

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

Думайте о контенте при разработке эскиза

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

Конечно же, есть еще очень много вещей, о которых надо подумать, и вы, в конце концов, составите свой список «О чем нельзя забывать» в ходе проработки проекта. Сейчас же давайте обратим внимание на перечисленные выше элементы.

Текст

Перед тем, как вы скажете: «Эй, подождите, разве вы не говорили мне только что, что мне не нужно отрисовывать текст на эскизе?», выслушайте меня. При разработке эскиза необходимо обратить внимание на пару вещей, связанных с текстом: ширина колонки и размер шрифта, оба из которых зависят от пропорций экрана и других элементов на странице.

Необходимая ширина колонки вполне очевидна, но определить ширину колонки с реальным текстом бывает достаточно сложно. В этом случае перенос эскиза непосредственно на устройство может дать вам представление о реальном пространстве, с которым вам предстоит работать. Другой использованный мной метод состоит в том, чтобы создать простую HTML-страницу, содержащую только текст, и открыть ее в браузере устройства (или даже на эмуляторе — такое решение, конечно, не является оптимальным, но все же дает возможность получить более-менее реалистичный вариант). Если текст кажется вам слишком крупным или слишком мелким, вы можете изменить размер шрифта. Как только вы определите подходящий размер, вы сможете сделать ваши эскизы чуть более реалистичными.

Подумайте о размере ссылок — не только о размере шрифта, но также и о пространстве вокруг них. Эти 2 фактора обеспечивают кликнуть или тапнуть по ссылке (или кнопке) — в большие кнопки и ссылки легко попасть, но и ссылки с меньшим размером текста ничуть не хуже, если добавить свободного пространства вокруг них. Не стоит забывать о вероятности того, что вам придется вносить изменения при разработке прототипа, независимо от того, как именно вы решили представить ссылки на эскизе.

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

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

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

Вспомним подход Брайана Ригера (Bryan Rieger) к разработке сначала в виде текстового представления и подумаем, что бы вы сделали до определения самой первой контрольной точки, как будто у вас в распоряжении есть только HTML и CSS — иными словами, если бы у вас не было Javascript. Это означает, что вы не можете свернуть меню в верхней части экрана и разворачивать его при нажатии пользователя на экран. Если ваше меню расположено в верхней части, то оно раскрыто и занимает достаточно большую часть пространства.

Это весьма противоречивая тема, и даже гуру доступности не могут прийти к общему решению: в конце концов, Javascript в настоящее время является технологией, совместимой с понятием доступности. Но она не является необходимой, когда речь идет о доступности. Необходимо задуматься, что происходит, если в браузере отсутствует поддержка Javascript, или если реализация Javascript, доступная на устройстве, отличается от той, что вы ожидаете. Ваш контент будет определенным образом представлен прежде, чем Javascript сделает свое дело, вне зависимости от того, какой браузер используется. Так почему бы не подумать о его (контента) первоначальном виде?

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

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

Помните, что Javascript и CSS позволяют вам изменять положение элементов на экране. Это знание должно помочь вам сверстать отличную страницу с помощью чистого HTML, а затем вы можете использовать Javascript и CSS, чтобы оживить ее. Это основа принципа прогрессивного улучшения.

Таблицы

Таблицы! О, горе для дизайнера отзывчивых интерфейсов (подождите, или горе — это изображения? Или видео? Или расположение элементов? Ох). С таблицами сложно сладить на маленьких экранах. Я был бы рад сказать вам, что у меня есть решение, но у меня самого много вопросов. Надеюсь, они подтолкнут вас к решению проблем. Правильным решением будет держать их в голове во время разработки эскиза.

Во-первых, с какими таблицами вам придется иметь дело? Узкими? Широкими? С числовыми значениями или с текстом? Если у вас уже есть готовый контент, вы сможете ответить на эти простые вопросы. Как только вы определитесь с ответами, постарайтесь некоторым образом упорядочить типы таблиц, с которыми вам предстоит, разделив их на классы (рисунок 7.7):

Рисунок 7.7

Рисунок 7.7: Существует несколько различных типов таблиц и различные способы адаптировать их для небольших экранов. (Источники: mobilism.nl и eu-verantwoording.nl)

Рисунок 7.8

Рисунок 7.8: Один из вариантов адаптации таблиц для небольших экранов — представить каждую строку таблицы в виде блока.

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

Хорошая новость в том, что то, что вы делаете для небольших экранов, вовсе не обязательно делать на экранах больших размеров. Вот почему сейчас, когда все, что нужно — это подготовить скетчи (что не займет много времени) самое время подумать об изменениях, которые вы сделаете на каждой контрольной точке.

Что делать, если вы зашли в тупик

Каждый дизайнер когда-нибудь заходит в тупик. Ничего страшного, если вы один из них. Существует бесчисленное множество решений этой проблемы, начиная от вопроса самому себе «а что, если» («А что, если это была бы не таблица, а список?» — спросил я себя перед тем, как разбить на блоки таблицу участников на сайте Mobilism), и заканчивая клише в любой непонятной ситуации — ложитесь спать, что вы и так регулярно делаете. Причина того, что эта глава так подробно затрагивает создание эскиза в том, что само рисование стимулирует ваш мозг для разработки новых идей, если вы уделите этому достаточно внимания, чтобы выйти из зоны комфорта сиюминутных решений.

Если проблема в том, что вы зашли в творческий тупик, то для вас существует множество вдохновляюших книг и ресурсов, чтобы запустить ваш внутренний творческий двигатель. Несмотря на то, что существует множество ресурсов о дизайне и творчестве самих по себе (например, обратите внимание на классику — книгу Эдварда де Боно (Edward de Bono) «Нестандартное мышление»), величайшее вдохновение может прийти вовсе не из мира дизайна.1 Попытки совместить обычно несовместимое могут привести к удивительным результатам. Это простой прием, но я часто использую «Непрямые стратегии» Брайана Ино (Brian Eno) и Питера Шмидта (Peter Schmidt), чтобы заставить себя подойти к проблеме с другой стороны.2 В худшем случае вы просто получите море удовольствия. В лучшем случае вы получите отличную идею!

Если ваша проблема в том, что вы не уверены, как следует поступить с чем-либо в контексте отзывчивого дизайна, нет ничего плохого в изучении того, как другие решили проблемы, похожие на вашу. Просто убедитесь, что вы используете ваш творческий потенциал и адаптируйте найденную идею к вашей ситуации. В конце концов, вы же дизайнер. Во время написания этого текста я обнаружил, что «Это отзывчиво» («This Is Responsive») Брэда Фроста (Brad Frost) — это одна из наиболее исчерпывающих доступных коллекций шаблонов проектирования отзывчивого дизайна.3 Вы можете потратить несколько часов, изучая ее, и вы определенно найдете что-нибудь, что выведет вас из ступора.

Фрагмент книги Стивена Хэя «Рабочий процесс проектирования отзывчивого дизайна». Copyright © 2013.
Использовано с разрешения Pearson Education, Inc. и New Riders.


Примечания

1. Эдвард Боно, «Нестандартное мышление» (Viking, 2009).

2. [http://en.wikipedia.org/wiki/Oblique_Strategies][4]

3. [http://bradfrost.github.com/this-is-responsive/][5]

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом редакторам Антону Немцеву в skype ravencry, Константину Гупалову в skype cosmik_soul или в skype matmuchrapna доброму Владимиру Старкову.

Stephen Hay
Автор:
Stephen Hay
GitHub:
stephenhay
Twitter:
@stephenhay
Сaйт:
http://www.the-haystack.com/
Сергей Смольников
Переводчик:
Сергей Смольников
Мой Круг:
http://sergey-smolnikov.moikrug.ru/
Twitter:
@smolnikov
GitHub:
smolnikov