KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Интернет » Элиот Стокс - Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки

Элиот Стокс - Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Элиот Стокс, "Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки" бесплатно, без регистрации.
Перейти на страницу:

Когда iPhone заставил нас осознать, что наша работа не всегда будет «[наилучшим образом] просматриваться на современном браузере в 1024 пикселей или больше», нашей первой реакцией было создать специфический дизайн страницы для iPhone в дополнение к тому, что есть для настольного компьютера. Это тут же увеличило время на разработку, обратную связь, корректировки и утверждение.

Чем больше появлялось смартфонов, электронных читалок и планшетов, тем прочнее у боссов и заказчиков входило в привычку просить специфические версии сайта или приложения для них[137].

• iPhone

• Android

• iPad

• Kindle Fire

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

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

Как говорит Стефани Ригер в своей статье «„Проблема“ с Андроидом» («The ‘Trouble’ With Android»[138]):

«По факту разработка под фиксированный экраный размер никогда не была хорошей идеей. […] слишком много вариантов, даже среди «популярных» устройств».

Так, вместо того чтобы думать об индивидуальном дизайне для отдельных устройств, мы должны подумать, как советует Итан Маркот, о простом дизайне, имеющем много аспектов, которые находятся в непрерывном и гибком ряду[139]:

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

Я люблю такой метод объяснения дизайна в отзывчивом контексте – много аспектов в одном опыте использования, потому что он хорошо отражает, что такое «смена положения дел», как описывал в своем «Дао» Джон Элсоп.

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

Отсюда возникают вопросы. Если бы мы не могли делать отдельные макеты с неизменяемой шириной, что бы мы делали? Как бы выстроили процесс? Как бы создавали дизайн для Интернета без границ?

«Эй, а я вот что сделал!»

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

Для дизайнеров

Photoshop и Fireworks – невероятные инструменты для творческих экспериментов и наши помощники в решении проблем и определении визуального направления проекта. Иногда даже сам процесс использования Photoshop и Fireworks помогает нам, порой случайно, достичь результата, которого трудно добиться другими средствами. В конце концов, результат – это нечто, на что мы можем ориентироваться и сказать нашим боссам и заказчикам: «Эй, а я вот что сделал!»

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

Но не все браузеры могут воспроизводить дизайн одинаково. У всех разные возможности, которые статические изображения игнорируют. Так что в нашей глупости никто не виноват, когда мы тратим часы, влезая в тонкости наших HTML и CSS или применяя «заплатки» на JavaScript в тщетной попытке сделать так, чтобы наш сайт выглядел одинаково во всех браузерах, как на статичном макете.

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

Для разработчиков

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

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

Для заказчиков

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

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

Дизайн – это не всегда разметка

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

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

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

Сначала дизайн компонентов

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

• прямоугольники (блоки);

• таблицы данных и другие виды информационных панелей;

• изображения (контент и иконографика);

• элементы интерфейса (карусели и галереи изображений и пр.);

• навигация (несколько уровней);

• шрифт.

Обратите внимание: это важная часть! Дизайн в отсутствии разметки становится стилизацией этих компонентов. Как они выглядят сейчас – это то, что мы выражаем через дизайн. Более точно: впечатления и ощущения от этих компонентов – это то, над чем дизайнеры могут и должны работать в первую очередь, задолго до того как у них возникнет мысль о расположении. Мне нравится размышлять о подходе, каким я разрабатываю компоненты страницы сначала на атомарном, самом крошечном уровне.

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

Мудборды

Мудборды (mood boards), или карты настроений, долгое время оставались невероятным методом для собрания вдохновляющего материала. Хранили ли мы эту коллекцию на наших компьютерах в приложениях наподобие Evernote, использовали ли онлайн-сервисы типа Pinterest, или просто крепили их на паспарту или пробковую доску, все это комбинация различных элементов, выражающих настроение. Наши мудборды могут иметь современное, безвкусное или традиционное восприятие, но как бы мы их ни называли – образом, настроением или индивидуальностью, – необходимо помнить о важном: мы описываем стиль. Конечно, мы не должны начинать процесс разработки с бумаги, ножниц и клея. Мы можем, если захотим, и не пачкать наши руки.

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*