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

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

Какое-то время этот сайт сияет на просторах Интернета. Однако контент не обновляется, технологии движутся вперед, а вкусы и пристрастия меняются. Некогда новый блестящий сайт постепенно блекнет до тех пор, пока компания не начинает стыдиться его.

Через пару лет кто-то из руководителей вновь видит необходимость сделать что-то с сайтом, и процесс начинается сначала.

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

Причины могут быть следующими:

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

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

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

• Периодическая глобальная реконструкция сайта невыгодно сказывается на расходе денежных средств, так как это требует солидных инвестиций каждые несколько лет.

• Тестирование эффективности комплексной переделки сайта – процесс сложный, так как изменяется очень многое.

• Затяжное отсутствие обновлений дает пользователям мало оснований для возвращения на ваш сайт.

Во многих случаях я советую своим клиентам отказаться от глобальной реконструкции в пользу постепенной перестройки сайта.

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

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

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

Несмотря на то что я фанат поэтапного усовершенствования сайтов (т. е. перегуппировки), чаще всего в моей работе, которой я занимаюсь в своем агентстве Headscape, все-таки приходится полностью переделывать их. Мы стараемся, где только возможно, использовать текущее состояние сайта как отправную точку, но часто его создание происходит с нуля, без опоры на предыдущий опыт. Все это потому, что при создании сайтов в редких случаях разработчики думали об их долгосрочном развитии. Жизни сайта после его создания придавали мало значения. Позже в этом разделе мы обсудим данную проблему.

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

В своей статье, написанной в поддержку поэтапных изменений[2], Якоб Нильсон говорит:

Другими словами, любой сайт со временем нужно будет переделывать полностью.

Вторая проблема, связанная с поэтапным изменением, это его влияние на базовый код. Как-то в нашем агентстве мы более шести лет работали с одним из клиентов. Это время было потрачено на непрерывный процесс улучшения и поэтапного изменения сайта. Добавлялись новые функции, в то время как другие выбрасывались. Дизайн менялся на основании обратной связи с заказчиком. Все эти изменения в конце концов превратились в кошмар. Одна часть сайта была написана на классической ASP[3], другая часть на. NET[4]. CSS-файлы[5] пухли от строк кода, в которых больше не было необходимости. Мы планировали и документировали так хорошо, как только могли, но в итоге стало понятно, что весь базовый код придется переписать.

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

Несмотря на то что процесс поэтапных изменений предпочтительнее, периодическое полное переделывание сайта все еще имеет смысл.

Суть в том, чтобы распознать признаки, которые дадут нам знать, когда требуется полная переделка.

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

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

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

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

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

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

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

Как отмечает в своей статье[6] Кэмерон Молл, переделывать сайт просто из-за того, что он внешне «постарел», недостаточно. Изменения должны приводиться в действие бизнес-задачами.

Типичные причины для изменений следующие:

• Изменение тенденций рынка.

• Изменение бизнес-модели.

• Падение конверсии.

• Рост требований о поддержке сайта со стороны клиентов.

• Смена позиционирования бренда.

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

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

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

К сожалению, изменение сайта сопряжено с определенными опасностями.

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

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

Хотя любой проект индивидуален, ниже я представил самые большие проблемы, с которыми я столкнулся за 16 лет моей работы веб-дизайнером:

• Расширение рамок проекта.

• Принесение в жертву стиля и трендов.

• Создание сайта без учета того, будет ли возврат инвестиций.

• Негативная обратная связь.

Ничто так не бросает в дрожь любого дизайнера, чем фраза: «У меня есть идея!» – услышанная из уст заказчика.

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

Как же тогда поступить с изменением технического задания? Есть один выход – упереться рогами и сказать: «Нет». Но это может привести к конфронтации и разрушить ваши отношения с клиентом.

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

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

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

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

Заморозка спорных вопросов до второй стадии имеет три преимущества:

• Заказчик гораздо реже навязывает идеи, как только видит свой восхитительный новый сайт.

• Создание нового сайта не будет тормозиться деталями, что вероятнее всего позволит запустить его вовремя.

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

Но не только обсуждение рамок проекта вселяет ужас в наши сердца.

Еще одно восклицание, от которого веб-дизайнеры бледнеют, это что-то вроде: «Мой сын подсел на Facebook. На нашем сайте должен быть Facebook». Не вопрос, Facebook – это не проблема. Но заказчик запросто может сказать: «У наших конкурентов крутой сайт. Мы хотим такой же» или «Нам нужен веб-два-нольный сайт».

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

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

Самая мощная защита в борьбе с модой – это задать простой вопрос: «Зачем?» Ответить, что это «круто» или «в тренде», будет недостаточно. Нам нужно спросить, почему определенная идея хороша, и привести реальные деловые доводы. Мы должны увязать их с нашим выбором и выбором заказчика.

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

Если это не даст желаемых результатов, действуйте дальше и задайте ему вопрос, откуда он ожидает возврата инвестиций.

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

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

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

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

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

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

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

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

Когда заказчик или пользователь видят новую разработку, они дают поспешную оценку, которая редко отражает их конечное восприятие.

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

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

Во-вторых, активно побуждайте клиента использовать это время для того, чтобы «переварить» дизайн. Объясните ему доходчиво, что первая реакция – не всегда самая правильная. Пусть заказчик вернется к дизайну через какое-то время, прежде чем он выскажет свое мнение.

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

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

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

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

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

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

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

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

Итак, в чем же суть исследования?

Количество проводимых вами исследований должно быть пропорционально ценности проекта. Размер неважен, вы должны провести хоть какие-то изыскания. Меня часто удивляет отсутствие базовой информации в обычной заявке. В требованиях часто не хватает таких фундаментальных вопросов, как:

• Для чего нам сайт?

• Чего мы ждем от сайта?

• Как мы сможем измерить его эффективность?

• Что будет делать пользователь на нашем сайте?

Опрос заинтересованных лиц – это полуструктурированная дискуссия с теми, кто извлекает пользу с сайта. Это может быть тот, кто непосредственно работает на сайте (например, контент-редактор), или отдельные лица (например, руководители отделов), которые надеются с помощью сайта реализовать свои бизнес-задачи.

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

Допуская, что заказчик откровенен на фазе исследования, у нас есть пять вариантов (в большинстве случаев выберем только один или два):

• Стратегический анализ

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

• Эвристический анализ

Так же, как и стратегический, эвристический анализ выявляет силу и слабость существующего сайта. Разница в том, что эвристический анализ делают с помощью оценки нескольких критериев (от 1 до 3). Эвристический анализ дает оценку сайту, но не в плане стратегии улучшения.

• Конкурентный анализ

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

• Аналитический отчет

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

• Персонажи

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

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

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

Я вовлекаю заказчика в несколько этапов разработки дизайна:

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

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

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

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

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

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

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

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

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

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

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

Вспоминаю, как несколько лет назад я делал дизайн в отрасли высшего образования. Сайт был прямо нацелен на то, что тогда называлось «поколением MySpace»[7]. Лично я ненавидел этот дизайн, и мой заказчик тоже.

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

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

А как вы будете уговаривать клиента принять метод тестирования при переделывании его сайта?

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

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

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

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

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

Есть несколько возможных вариантов, и выбрать правильный очень важно. Я остановлюсь на трех, которые я применяю чаще всего.

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

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

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

В опрос хорошо включить следующие пункты:

• Выбор между двумя подходами к дизайну, с едва уловимой разницей.

• Получение мнения по поводу того, правильно ли дизайн отражает ключевые качества, характеризующие бренд (например, свободный и небрежный либо профессиональный дизайн, консервативный или либеральный?).

• Вопрос пользователям, какими опциями из ограниченного набора они будут пользоваться.

• Проведение сортировки закрытых карт (где пользователь должен систематизировать страницы по категориям).

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

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

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

Флеш-тест основывается на контенте и визуальной иерархии. Вы показываете дизайн пользователям на несколько секунд и потом убираете его. Затем вы просите их воспроизвести элементы страницы.

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

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

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

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

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

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

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

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

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

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

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

• Вы согласны с тем, что изменение дизайна отражает ценность бренда компании?

• Соответствует ли переделывание сайта тем бизнес-задачам, которые мы обговаривали?

• Соответствует ли переделывание сайта персонажам, которые мы обсуждали?

• Побудят ли пользователей утвержденные призывы к действию после переделки сайта?

• Отражает ли дизайн принятые карты настроений и прототипы?

• Все ли подходящие отзывы, полученные из тестирования, мы учли?

Я должен признаться, что как веб-дизайнер я не всегда был дальновидным в своем методе создания сайтов для заказчиков, что шло во вред мне и им. Уверен, что я не один такой.

Мы совершенно не виноваты в этой недальновидности. По большому счету она – порождение культуры, о которой я говорил ранее. Когда клиент каждые несколько лет утверждает новый сайт (зачастую, всякий раз с разными дизайнерами), мало толку планировать его долгое существование.

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

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

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

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

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

Нам следует помнить, зачем и что мы делаем как веб-разработчики. Если мы об этом забудем, то начнем практиковать неправильные вещи. Речь идет о веб-стандартах.

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

Веб-стандарты помогают обеспечивать будущее сайтов. Но все равно я вижу тревожное количество сайтов, созданных с CSS, HTML и JavaScript, в которых это разделение не так явно: строки JavaScript либо встроены непосредственно в код HTML, либо рассчитаны на присутствие определенных элементов HTML, а тот, в свою очередь, «нашпигован» классами и идентификаторами элементов, чья единственная цель – задание внешнего вида страницы. Не поймите меня неправильно: я не ярый борец за чистоту кода. Я знаю степень неминуемости таких накладок в коде. Когда вы пишете код, спросите себя, как ваши решения повлияют на обновления через год-другой.

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

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

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

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

Шаги, которые следует предпринять, будут зависеть от того, какую мобильную стратегию предпочтет клиент. У него есть несколько вариантов, и нам надо рассказать клиенту о них.

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

Так или иначе, здесь представлены некоторые моменты, которые вам необходимо обсудить с заказчиком:

• Какие «родные» характеристики должны быть доступны?

• Вы можете позволить себе разработку под множество платформ?

• Вы захотите разделить доходы с владельцем магазина приложений?

• Ваше приложение будет доступно через магазин приложений?

• Есть ли какие-либо выгоды от распространения приложения через такие магазины?

В предыдущем разделе мы обсуждали требования к сайту. Здесь мы поговорим о том, как выполнить их технически. Остерегайтесь заявлений типа: «Мы хотим, чтобы все было так, как в текущей системе» – если только не вы ее создали! Если клиент этого хочет, убедитесь, что вы получили подробную информацию обо всем том, что должно быть в новой системе.

Рисунок 2.1. Любой, кто выбирает CMS, столкнется с массой опций. Чтобы решить, что сработает для вашего проекта, нужно понимать технические требования

Не сделаете этого – готовьтесь к тому, что перед самым запуском вас спросят: «А как эта система поддерживает задачу, которую пол-офиса делает каждый день?» (хоть это и не так на самом деле). И таким образом заставят вас вносить значительные дополнения в проект. Знаю это по своему опыту!

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

В зависимости от типа сайта конверсии[11] могут быть такие: покупка товара через сайт, подписка на получение пробной версии продукта, на e-mail-рассылку или заполнение формы. Если потребуется такой вид тестирования, как он будет осуществляться с помощью CMS? Если часть посетителей нужно отправить на одну версию страницы, а остальных – на другую, здесь не обойтись без стратегии. Об этом виде тестирования вы можете прочесть на сайте Smashing Magazine в исчерпывающей статье «Исчерпывающее руководство по А/В тестированию»[12] либо на сайте СилаУма (примеч. ред.)

Добавить функцию электронной коммерции на сайт может оказаться простым делом. Возможно, достаточно будет всего лишь поставить несколько кнопок «Купить сейчас» платежной системы PayPal[13]. Но могут быть и трудности, например, если вам придется настраивать свой магазин на поддомене готовой платформы онлайн-магазина или разрабатывать свой собственный. Конечно, сегодня процесс продажи товара напрямую через сайт не надо усложнять. Но все же есть над чем поломать голову, когда вам предстоит сделать правильный выбор в зависимости от вида продукции. В этом разделе мы пробежимся по некоторым из вариантов. Несомненно, вам будет это на руку, если вы в первый раз внедряете функцию электронной коммерции – ведь это все равно что ступить на необитаемый остров.

Что продаем?

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

Как покупать?

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

Будут ли на сайте специальные предложения – «При покупке одной вещи, вторая – в подарок!», «Скидка 20 %», «Две вещи по цене одной!», «Купите Х, получите Y за полцены!»? Реализовать подобные предложения в созданной по заказу системе может быть достаточно непросто. А если вы используете коробочную CMS, то нужно знать, сможет ли она поддерживать их.

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

Рисунок 2.2. Вещь, которая, кажется простой, на самом деле может иметь ряд опций (например, футболка может быть женской или мужской и разных размеров)

Учетная запись и отслеживание заказа

У пользователей может быть опыт использования учетной записи (аккаунта) и отслеживания заказов. Возникают вопросы: обязательно ли пользователям создавать учетную запись? Смогут ли они отслеживать свои заказы и видеть их путь от «В обработке» до «Отгружено»? Аккаунт должен иметь такие основные функции управления, как восстановление забытого пароля или обновление контактных данных.

Как принимать оплату?

Вероятно, вам понадобится принимать платежи от покупателей по кредитным и дебетовым картам. Есть несколько вариантов, разных по сложности и цене. Обычно платежи обрабатываются с помощью платежной системы, аккаунта продавца и платежного шлюза и программы-посредника SaaS (программное обеспечение как услуга). Принимать платежи онлайн через платежную систему – легко. Плюсы здесь в том, что создать аккаунт несложно, а интеграция может быть различной: от простого варианта – встраивания кода кнопки на страницу, до полной интеграции с вашей системой.

На платежном рынке есть и другие игроки, но большинство из них действуют в немногих странах. Причина в том, что большая часть законов о процедуре оплаты в каждой стране имеет свою специфику. Если вы будете принимать регулярные платежи, то вам могут пригодиться Chargify и Recurly. И хотя сейчас они доступны только в США[14], Stripe выглядит многообещающе как метод принятия платежей онлайн.

Чтобы напрямую принимать платежи по карте, избегая посредников, вам нужно завести аккаунт онлайн-продавца. Это позволит принимать платежи по кредитке и переводить деньги на ваш банковский счет. Если у вас есть действующий банковский счет для офлайновых продаж, вероятно, вы не сможете воспользоваться им для онлайновых транзакций. Транзакции через Интернет не совсем безопасны, поэтому прежде чем начать выполнять их, свяжитесь со своим банком. Банк посоветует защитить свой платеж, в большинстве случаев через провайдера платежных сервисов PSP (payment service provider), иногда называемым платежным шлюзом.

Рисунок 2.3. Stripe.com – это новый игрок на рынке, предлагающий простой способ приема платежей

Но что вы точно не должны делать, так это сохранять данные кредитной карточки, чтобы позже ввести их в терминал офлайн. Это противоречит условиям коммерческого договора. Поэтому, пока банк не даст вам свое письменное согласие и вы не выполните требования PCI DSS[15] (о них мы расскажем позже), просто не делайте этого.

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

• Через страницу платежей

Пользователь переходит с вашего сайта на защищенную страницу провайдера платежного сервиса и вводит данные карты.

• Через интеграцию по API[16]

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

Стандарт безопасности данных индустрии платежных карт (The Payment Card Industry Data Security Standard (PCI DSS)) представляет собой совокупность 12 детализированных требований, которые распространяются на все компании, принимающие оплату по картам. Это относится не только к транзакциям онлайн. Обычный офлайновый магазин, который принимает платежи онлайн, должен тоже подчиняться требованиям PCI DSS для обоих способов оплаты: офлайн и онлайн.

Если вы принимаете онлайн-платежи через платежную страницу, но не получаете, обрабатываете или храните данные по картам, то вы можете заполнить сокращенный PCI DSS опросник (SAQ A), чтобы подтвердить, что ваш PSP совместим с PCI DSS. Если как средство интеграции вы используете API, то он полностью должен соответствовать PCI DSS (даже если вы не сохраняете данные карты) и включать ежеквартальные проверки безопасности, подтверждающих постоянное соблюдение требований.

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

Хранение данных карты

Я настоятельно советую вам не хранить данные карты на сервере клиента, даже в зашифрованном виде. Хранение данных требует совместимости с PCI DSS и поддержки сервера, а также Сети, в которых эти данные будут находиться в безопасности.

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

Валюта и местные налоги

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

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

Рисунок 2.4. Платежная страница сайта. Включает НДС, скидку и приблизительную цену в долларах США. Несмотря на то что продается всего лишь один продукт, нужно принимать во внимание несколько величин

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

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

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

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

Покупатели ожидают, что они скачают цифровые продукты (такие как электронные книги, музыка и ПО) сразу же после их покупки. Доставка может быть оформлена в форме ссылки или страницы для скачивания в своем профиле (вместе с лицензионным кодом если нужно).

Система должна обезопасить продукты до их приобретения и обеспечить в аккаунте клиента область, где они будут доступны (или как минимум отправлять ссылку на e-mail). Также можно генерировать код продукта. Опять же системы-посредники могут обеспечивать весь этот функционал в рамках оплачиваемых услуг.

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

Вот ряд других вопросов, которые надо задать себе или заказчику:

• Нужно ли вам контролировать остатки через сайт?

• Как вы будете поступать с заказами, которые выполнены частично?

• Должен ли сайт генерировать счета и товарные накладные или это будет происходить в офлайне?

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

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

Так мы создали новый интерфейс для нашей стандартной CMS-системы, который идентифицировался через сервер LDAP. Когда работаешь с такой системой-посредником, написать код ничего не стоит.

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

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

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

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

С этим мы ничего не могли поделать, и очевидно, что это время необходимо было включать в расписание проекта.

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

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

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

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

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

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

Если вы будете применять различные способы оплаты, то интернет-магазин понесет дополнительные затраты.

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

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

Но для того чтобы изменить язык на более «крутой», им потребуется серьезная переподготовка и много времени, потому что придется создавать новые библиотеки для базовых вещей. Это оправдает себя в том случае, если существующий язык мешает продвижению сайта (или из-за того, что мало кто из разработчиков знает его, или из-за того, что его развитие застопорилось). Предположим, ваша система создана на классическом ASP, и команда, которая поддерживает ее годами, знает этот язык. Однако он уже вытеснен ASP.NET (и не развивается настолько активно), поэтому строить на нем новую систему не имеет смысла. Кроме всего прочего, найти разработчиков, которые знают Classic ASP не так-то просто. Да и язык устарел настолько, что он не подходит для модернизации сайта.

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

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

Постигать что-то новое всегда интересно, но не кидайтесь от одного к другому, только потому, что это модно. Лучше знать один язык, но досконально, чем несколько, но поверхностно.

Если проект готовится для заказчика, скорее всего, он станет ограничивать вас во времени и бюджете. Ограничения могут иметь под собой как техническую подоплеку (например, требование создать и разместить сайт под определенную серверную архитектуру), так и политическую (например, требование использовать ПО с открытым кодом).

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

Например, сервер работает на Windows, а компания могла бы установить PHP; это спасло бы вас от головной боли при инсталляции, потому что есть некоторые различия между PHP на Linux и PHP на Windows (в основном если сервер работает на IIS, а не Apache).

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

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

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

Термин «открытый/исходный код» часто непонятен. Когда люди решают, что программное обеспечение должно быть открытым, обычно они не имеют в виду лицензию на него или бесплатное пользование. Все, что они хотят, это иметь возможность модифицировать (изменять) код, если нужно. Это позволит обезопасить себя в том случае, если разработчик стороннего продукта по каким-то причинам пропал или откажется от развития и поддержки продукта. Если от вас требуют использования ПО с открытым кодом, проясните для себя, что под этим подразумевается. Многие коммерческие продукты имеют незашифрованных и доступный для модифицирования код, но при то не имеют лицензии открытого исходного кода.

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

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

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

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

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

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

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

Лучше делайте свои изменения через официальный API. Если не сможете, все равно не взламывайте программу. Потому что то, что у вас получится, вы едва ли сможете поддерживать.

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

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

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

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

Рисунок 2.5. На WordPress оживленные форумы. Они для людей, которым нужно помочь в выборе правильного ПО

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

Третий способ решения, который нам нужно обсудить, – это программное обеспечение как услуга (SaaS), известные также как облачное ПО. Есть системы управления контентом (CMS), которые, к примеру, используются в электронной коммерции. В них реализован различный функционал, начиная от простого «положить в корзину» и страницы оплаты и заканчивая полноценным интернет-магазином. Такое решение привлекательно тем, что вам не нужно ничего устанавливать, чтобы запустить и поддерживать сайт. Может лишь возникнуть необходимость настроить некоторые опции и выбрать шаблон.

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

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

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

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

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

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

И все равно кто-нибудь да расскажет вам о своей любимой CMS и в восторге станет доказывать, почему она лучшая из лучших. Этих людей мы называем «евангелистами»: они так любят софт, которым пользуются, что и представить себе не могут, что у кого-то может быть что-то другое. Я сам являюсь поставщиком CMS. Именно поэтому я иногда имею свою выгоду от «евангелистов» в среде наших пользователей. Но я и первый, кто в случае, если наше решение не вписывается в проект, скажет об этом прямо.

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

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

Многим хостинг-провайдерам удается сбывать свой продукт на рынке чисто из-за низкой стоимости. Можно достать хостинг за $10 в год. Но то, что есть такой дешевый хостинг, еще не говорит о том, что надо пользоваться им. Он может в результате обойтись вам гораздо дороже, чем качественный хостинг с разумной, обоснованной ценой. Хороший хост стоит денег. А если заказчик толкает вас к дешевому провайдеру, то, надеюсь, что, прочитав этот раздел, вы вооружитесь неплохими контраргументами.

Веб-хост с оплатой $10 в год, чтобы «сколотить» хоть какие-то деньги, должен разместить сотни сайтов на каждый физический сервер. Соответственно, это может привести к перегрузке, и какой-нибудь сайт с тяжелым трафиком застопорит остальные или даже выведет их в офлайн.

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

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

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

• PHP версии 5.2.4 или выше,

• MySQL версии 5.0.15 или выше,

• модуль Apachemod_rewrite.

Рисунок 2.6. Проверьте последнюю стабильную версию PHP на php.net

Если вы используете серверный язык и базу данных, убедитесь, что ваш хост поддерживает их, а также и минимальную версию, которую требует ПО. Правило номер один: держитесь подальше от хостов со старыми версиями серверных языков. Вы можете ознакомиться с современной версией PHP на сайте php.net, проверив раздел «Стабильный релиз». На момент написания последняя версия – 5.3.9. Если хост поддерживает обновления, то его версия – 5.3, естественно, версии продукта не должны быть моложе, чем 5.2.4, как требуется для WordPress.

Хост может поддерживать серверы со старыми версиями PHP, если нужна поддержка пользователей, работающих на них. Но он должен быть в состоянии также их обновлять их по требованию или создавать новые аккаунты (учетные записи) для новых серверов.

Базы данных

Если вам нужна база данных для сайта (например, контент блога WordPress хранится в базе данных MySQL), посмотрите, предоставляет ли хост хотя бы одну. Если у вас свои скрипты, то внедрить каждый с собственной базой данных, возможно, будет легче. Поэтому проверьте, какое количество баз допустимо. Что касается скриптового языка сервера, выясните, совместима или нет версия базы данных того софта, который предлагает хост, с вашими скриптами.

Вам нужна поддержка e-mail-сервера?

Если вы хотите использовать один и тот же сервер как для e-mail, так и хостинга, узнайте, что он предлагает. Есть ли у него нужный вам web-mail? Сможете ли вы использовать e-mail с протоколами POP или IMAP? Легко ли использовать интерфейс для установки почтовых сообщений? Есть ли антиспам-фильтр?

Нужно ли вам размещать несколько доменов на одном сайте?

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

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

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

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

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

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

Как мы уже говорили, языки сервера нужно обновлять в целях безопасности и совместимости, как и настольные компьютеры. Если хостинг поддерживает очень старую версию языка, это говорит о том, что его серверы не современные. А это значит, что они уязвимы. Вы должны вникнуть в эти проблемы и попытаться установить скрипт с открытым кодом, который основан на современной версии языка программирования. Многие провайдеры дают гарантию на время работы, обычно в процентах: «Стопроцентная гарантия на время работы». Имеется в виду, что ваш сайт будет функционировать на 100 % в течение всего времени работы. Но не обольщайтесь и не рассчитывайте на многое!

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

Когда я выбираю хостинг, я мало обращаю внимания на заверения о времени доступности серверов по словам самого хостера, я спрашиваю пользователей этого хостера об этом и о работе техподдержки. Будьте осторожны! Не нарвитесь на хостинг компании, которая занимается перепродажей серверов крупных поставщиков. Любой может купить сервер у крупного хостера и начать распродавать его дисковое пространство, при этом не имея малейшего представления о хостинге вообще. В этом случае, если ваш сайт упадет, вы столкнетесь с тем, что это посредник не в силах ничего с этим сделать. Он лишь может посоветовать вам обратиться напрямую к хостеру. С посредником, который болтался между вами и теми, кто действительно решит ваши проблемы, будет покончено.

Рисунок 2.7. Хостинг компания Memset предлагает ряд личных (приватных) виртуальных серверных пакетов

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

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

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

А это значит, что вы можете изменять сервер и устанавливать на нем сложные сайты.

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

Две наиболее известные панели – это Plesk и cPanel (которые включают панель Web Host Manager). С помощью этих средств вы сможете установить новый сайт на сервере и актуализировать обновления, а также компоновать сервисы, доступные для индивидуальных сайтов. В сущности, имея виртуальный выделенный сервис, вы сами себе хозяева.

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

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

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

Хороший тому пример – продажа билетов. Наплыв пользователей на сайт наблюдается, когда в продажу выбрасывают билеты на какое-то популярное событие, но все остальное время трафик остается низким. С облачным хостингом у вас будет, когда нужно, доступ к дополнительным мощностям (конечно же, не бесплатно), а резервная мощность сохраняется круглый год.

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

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

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

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

Если вы дорабатываете «живущий» сайт или перекраиваете интерфейс пользователя, а код оставляете более или менее нетронутым, мой вам совет: экспортируйте базу данных и скачайте все файлы (об этом прочтете позже в статье «Перенос вашего сайта»). Это нужно для того чтобы настроить разрабатываемую и промежуточную версии сайта в точности, как на действующем сайте. Если база данных с рабочего сайта содержит конфиденциальную информацию о пользователях, лучше использовать псевдозаполнение данных. Не только для того чтобы защитить данные, но и во избежание их случайной отправки 10 000 пользователям из вашей локальной системы, когда будете что-то проверять!

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

Он так же прост, как и поддомен, который указывает папку на вашем текущем сервере. Это позволит вам протестировать сайт на реальном сервере с заданной конфигурацией и всеми корректными путями.

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

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

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

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

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

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

Рисунок 2.8. Beanstalk сервис для контроля версий

Существует несколько систем управления версиями. Вы, наверное, слышали о таких, как Subversion и Git. Обычно каждый выбирает, кому что нравится. Так как для выполнения работы вы можете менять сервер, то используя такие веб-сервисы, как GitHub или Beanstalk, вы можете быстро приступать к работе. Beanstalk имеет отличное руководство по управлению версиями на своем сайте[19].

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

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

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

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

Избегайте предварительного просмотра сайта с тильдой (~) или с вашим именем пользователя, иначе пути и ссылки побьются.

Если вы работаете на приложениях не от Microsoft, то, скорее всего, вы используете MySQL. MySQL – это база данных, используемая для большинства приложений с открытыми «исходниками». Ее любят разработчики, которые работают с PHP, Python и Ruby on Rails.

Первое, что вы должны знать при работе с такой базой данных, как MySQL, это то, что в ней нет файла данных для скачивания и пересылки. База хранится внутри MySQL сервера. Чтобы получить данные, вам надо будет подключиться к нему. Многие серверы устанавливаются с PHPMyAdmin – веб-приложением, которое позволяет управлять базами данных через браузер.

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

Если ваша почта будет располагаться на новом домене, тогда установите почтовые учетные записи так, чтобы они были готовы к использованию, как только домен будет прикреплен к новому серверу.

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

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

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

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

Если это ваш случай, то попросите вашего хостинг-провайдера (и разработчика, если он у вас есть) сделать все лучшим образом.

HTML5 – это уйма всего. Мы уже далеко ушли от последней основной «версии» HTML. Сообщество по развитию гипертекстовых технологий (WHATWG) ссылается на нее как на «HTML: Живой стандарт» (от упоминания числа 5 отказались). А это значит, что у HTML нет версий. Как мы говорили, производители браузеров выбирают лучшие свойства для рендера, поэтому и отличается поддержка разных элементов разными браузерами.

Может быть, вы слышали о Всемирном консорциуме Сети (W3C). Мы уже упомянули о сообществе WHATWG. Оно было основано производителями браузеров Apple, Mozilla и Opera. Обеспокоенные тем, что W3C недостаточно занимается развитием HTML, они решили организовать свою группу.

Большая часть работы группы WHATWG пересекается с W3C, а в лицензии на спецификацию говорится, что «вам предоставляется лицензия на использование, воспроизведение и создание производных этого документа».

W3C в самом деле помогает в работе. Организация не разрабатывает стандарты, но охотно дает рекомендации. И хотя W3C финансируют большие компании – производители компьютеров и браузеров, она тем не менее специализируется на открытых стандартах, которые не ставят во главе угла какую-либо одну компанию.

Что же, как разработчик, вы можете быть уверены, что все новые разработки в HTML (особенно в области веб-приложений) создаются при значительной финансовой поддержке производителей браузеров (Webkit, Gecko и Opera) и со временем одобряются W3C.

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

Рисунок 3.1. Сайт Caniuse (smashed.by/ciu) демонстрирует, в каких случаях вы можете или должны использовать возможности HTML5

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

Только маги и чародеи могут знать, насколько широко поддерживается какая-либо заданная функция. Если вы не относитесь к их числу, возьмите себе в помощь сайт When Can I Use[20]. На нем находится список возможностей, которые поддерживаются в современных версиях всеми основными настольными и мобильными браузерами, а также перечень возможностей, которые будут представлены в будущих версиях. Он доступен для поиска и даже подключается к Google Analytics, чтобы показать вам, какие браузеры использует ваша аудитория. А теперь давайте погрузимся и посмотрим повнимательнее на основы HTML.

[21]

Поройтесь в кладовой своей памяти. Можете припомнить полный DOCTYPE для HTML 4.01 (или для XHTML, коли на то пошло)? Не думаю. Давайте я покажу вам DOCTYPE для HTML5:

<meta http-equiv="Content-Type" content="text/html;

charset=utf-8">

Атрибут type можно задать и через ссылку на таблицу стилей <link rel=”stylesheet” href=”layout.css”>, и в теге script.

В прежние времена атрибут type мог использоваться в теге script, если вы хотели применить VBScript вместо JavaScript, но сегодня это уже не актуально.

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

Сначала о том, как браузер загружает файлы. После того как браузер загрузил и проанализировал HTML, он составляет список project assets, категорий[22] (изображения, CSS, JavaScripts и т. п.) и расставляет приоритетность их загрузки в порядке появления.

Раньше мы подключались к Интернету через телефонную сеть, которая слабо справлялась с несколькими одновременными подключениями. Сейчас пропускные способности значительно варьируются (особенно с учетом мобильных устройств). Поэтому сегодня браузеры ограничены в одновременной загрузке файлов с домена верхнего уровня. Вот почему некоторые разработчики используют сети доставки и дистрибуции контента или размещают файлы на поддомене (таком как assets.example.com); использование нескольких доменов дает разработчику больше слотов загрузки для скриптов, таблиц стилей, изображений и фреймов.

Рисунок 3.2. Yepnope: условный скриптовой загрузчик

Когда браузеры качают файлы JavaScript, они загружают по одному скрипту за раз, что позволяет им анализировать код и предзапускать магические оптимизации. Теперь, вместо того чтобы полагаться на удачу, мы можем использовать загрузчики скриптов (такие как LABjs, Yepnope, RequireJS и многие другие), чтобы одновременно загружать множество скриптов, устанавливать зависимости и определять, нужен ли вообще какой-то определенный скрипт.

Имеет смысл улучшить производительность страниц везде, где возможно. Компания Amazon утверждает, что увеличение времени загрузки страницы на 100 миллисекунд уменьшает количество продаж на 1 %[23].

Вооружившись этими сведениями, поговорим о моем любимом скриптовом загрузчике, Yepnope[24].

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

Для примера:

yepnope([

{

test: window.JSON,

nope: ‘/javascripts/json2.js’

}

])

Этот умный кусочек JavaScript проверяет, есть ли у браузера свой «родной» анализатор (парсер) JSON. И туда, где его нет (у браузеров IE 6 и 7), он загружает скрипт /javascripts/json2.js, (полифилл[25] JSON).

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

Первый – это асинхронный тег:

<scriptsrc=”/javascripts/application.js” async></script>

Асинхронный тег – это булевый атрибут, означающий, что его явное присутствие в браузере задает значение true, или «Да, пожалуйста, используйте этот функционал». Он велит браузеру выполнить application.js., как только оно будет доступно. Скрипты, которые загружаются асинхронно, выполняются, как только будут загружены, то есть не в порядке их появления в коде HTML

Стоит упомянуть, что нашим самым большим достижением стало уменьшение размеров скриптов в целом. Сначала мы добились этого, применив gzip-сжатие (как и для таблицы стилей, и HTML файлов). Чтобы добавить на сайт поддержку gzip, зайдите в репозиторий HTML5 Boilerplate на GitHub[26].

Если вы не знаете, как обслуживается ваш сайт, самое время ознакомиться с панелью инструментов для разработчика. На Webkit браузерах (Safari и Chrome) вы можете открыть ее, нажав Command + Option + I в системе Mac и Control + Shift + I в Windows.

Под панелью «Сеть» вы найдете список файлов, которые были загружены для текущей страницы. Можете проинспектировать запросы и заголовки ответов для каждого файла.

Рисунок 3.3. Панель инструментов для разработчика Safari отображает активность сети на Yepnope.

Рисунок 3.4. Файл был передан браузеру в предварительно сжатом виде

Второй совет, как улучшить производительность вашего сайта (вообще-то, лучший способ – это оптимизировать код), – объединить и сжать файлы.

Я советую вам применить компилятор UglifyJS[27].

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

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

Прежде чем использовать какой-то новый тег, не забудьте о так называемом HTML5 Shiv. Этот скрипт важен для нас. Без него Internet Explorer 6, 7 и 8 не смогут распознать незнакомые стили (т. е. новые HTML5-теги, которых не было, когда создавались указанные версии IE).

Вы можете скопировать HTML5 Shiv из сервиса Google Code, где выложен этот проект[28].

Также вы можете получить HTML5 Shiv, используя js-библиотеку Modernizr[29]. В этом разделе мы не говорим об этом скрипте подробно, но тем не менее держите его на вооружении. Я использовал его на каждом сайте, созданном за последние два года.

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

Применяйте одну из новых версий CSS reset, поскольку старые версии не задают нормированный стиль элементам HTML5.

Очень советую познакомиться с Normalize.css[30] Николаса Галлахера[31] и Джонатана Нила[32].

Многие из старых сценариев сброса (классический пример – сброс от Эрика Мейера) тяжеловесны: они сбрасывают каждый элемент, а некоторые их изменения можно оспорить, например тег strong при установке не выделяется жирным шрифтом по умолчанию. Normalize.css сбрасывает элементы более изящно и сглаживает некоторые причуды браузеров. Это позволит вам максимально нивелировать различия между ними. Джон Нил и Николас Галлахер «раскладывают по полочкам» все, что делают скрипты. Изучите подробно прокомментированный код – он фантастичен!

Дойдя до этого пункта, вы, наверное, подумали: «OK, пора начинать писать сайт, пользуясь самыми замечательными новейшими тегами!» Когда были установлены новые семантические теги, разработчикам пришлось потрудиться: проанализировать, какие классы иидентификаторы они будут применять для своих сайтов. Ничего экстраординарного они не обнаружили: на деле все они пользовались одними и теми же именованиями (иногда с небольшими перестановками).

Итак, возможно, имена новых тегов уже подходят для того, что мы делаем.

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

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

Если вам нужен простой критерий распознавания статьи, используйте такой практический прием: если часть контента все еще имеет смысл вне текущего контекста (т. е. если пользователь не видит элементы страницы с этим контентом), тогда это, скорее всего, статья. Отсюда – блоги и онлайн-новости.

Я использую тег article для набора контента, скажем, для списка презентаций, которые я представлял раньше, возможно, с кратким обзором:

Вы когда-нибудь использовали класс или идентификатор как «шапку» или баннер? Или даже для заголовка сайта? Тег header может использоваться как нечто большее, чем просто заголовок сайта. Его можно (но совсем не обязательно) применять внутри тегов article или section. Просто используйте его, когда нужно, чтобы блочный элемент разграничивал пространство на странице для ясности. Например, я часто храню заголовки и метаинформацию в шапке поста блога.

Тег footer аналогичен тегу header. Вы можете использовать его внутри тегов article или section, или глобально, внутри body.

Тег aside может использоваться на уровне страницы или внутри article. Его содержимое можно считать полезной информацией, но вовсе не основной.

Например, для мобильных версий своего сайта вы можете скрыть aside-элементы. Как бы вы ни обошлись с тегом, он заставит вас принять решение о контенте. Запись в блоге можно представить так:

Вы заметили в предыдущем примере новый тег? Тег time прост: используйте его для показа времени. Вы также можете представить машинно-читаемую версию.

Элемент nav явно предназначен для навигации сайта. Вы можете вставлять теги nav, чтобы создавать выпадающее меню. Тег не годится для списка презентаций, который я показывал вам, когда мы говорили о теге article. Приберегите nav для своего сайта, когда дело дойдет до структурной навигации сайта. Например:

Возможно, вы добавляете на свои страницы много изображений. А задумывались ли вы когда-нибудь о том, как лучше задать подписи к ним? Вот было бы здорово, если бы можно было аккуратно подписать изображение! Для этого-то нам и нужен тэг figure.

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

Div (division) означает «раздел», и порой нет лучшего тега для описания куска контента. Возможно, все, что вам нужно, это контейнер для применения стилей. Так бывает. Это не в упрек вам. Семантика – штука коварная. Если вы на самом деле не умеете описывать куски контента с использованием каких-то тегов HTML, о которых мы говорили выше, берите div и не казните себя за это.

Теперь, когда у нас есть несколько новых элементов для разметки блоков (т. е. section и article), простая структура старого документа, которую мы использовали, чуть-чуть изменилась. Элементы разметки блоков можно рассматривать как блоки всего html-документа. Другими словами, теги заголовков от h1 до h6 могут использоваться внутри них.

Но будьте внимательны! Вы можете столкнуться с чем-то подобным:

Роли стандарта доступности активных интернет-приложений WAI-ARIA (сокр. от Web Accessibility Initiative: Accessible Rich Internet Applications) всегда входили в состав современной технологии HTML. У многих разработчиков темнеет в глазах при одном только упоминании о них. Роли созданы для того, чтобы сделать сайты и приложения более доступными для пользователей с ограниченными физическими возможностями, которые полагаются на программы, читающие вслух текст с экрана. Разработчики, посвятившие себя этому благородному делу (на самом деле их не так уж и много!) постоянно говорят о важности WAI-ARIA, но профессиональное сообщество в целом их как будто не замечает.

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

Для слепых и людей с пониженным зрением WAI-ARIA роли описывают контекст и цель информации, лежащей за ним. Разделы страницы отличаются не только визуально, но и по контексту. А программа, читающая с экрана, может объяснять эту разницу пользователям и позволяет им без проблем взаимодействовать с разделами.

Я ни в коем случае не позиционирую себя как эксперта по стандартам доступности. Но очень постараюсь внятно и серьезно объяснить вам, почему важность стандарта WAI-ARIA не ограничивается только вопросами доступности. Если вы когда-нибудь пользовались блочными элементами, которые описаны в этом разделе, то, скорее всего, встречались с чем-то вроде этого:

А теперь поговорим об абсолютно новой теме: хранилище на стороне клиента в HTML5. На сегодняшний день мы имеем невеликий выбор средств для хранения данных у пользователя. Наиболее распространенным способом стала скромная куки-сессия. Но этому методу сопутствует множество маленьких проблем. И самые выматывающие из них – это следующие:

• Данные, которые вы сохраняете в сессии, перемещаются туда и обратно между клиентом и сервером при каждом запросе.

• Данные, которые вы сохраняете, имеют лимит в 4 kB.

• Все куки ограничены во времени.

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

С localStorage и sessionStorage, у нас есть два JavaScript API для сохранения строк для браузера. SessionStorage очищается, когда заканчивается сеанс пользователя (т. е. когда «вкладка» или «браузер» закрываются), а в это время localStorage хранится, пока разработчик (через JavaScript) или пользователь (через свои браузерные настройки) не решают удалить его.

Интерфейсы API виртуально идентичны – единственная разница будет в сроках хранения. Откройте свою панель инструментов разработчика в современном браузере (имеется в виду выпуска последних трех лет).

Введите localStorage.setItem (“name”, “Ben”). В Webkit-браузерах вы увидите мое имя, сохраненное под вкладкой «Ресурсы» (для этого вам нужно будет раскрыть “Local Storage”). Вы только что сохранили свой первый элемент данных в localStorage.

А теперь давайте извлечем то, что вы сохранили, используя localStorage.getItem(“name”). Вы увидите “Ben”, четко напечатанное в консоли.

И, наконец, чтобы очистить все после себя, воспользуйтесь либо localStorage.deleteItem(“name”), чтобы удалить мое имя, либо localStorage.clear(), чтобы убрать все из localStorage. Когда пользователи вызовут localStorage.clear(), они лишь очистят его для текущего домена.

Итак, если пользователь сохраняет какие-либо данные на сайте, расположенном на example.com, а потом переключают вкладки на google.com, они увидят, что у них нет доступа к данным, сохраненным ими на вкладке example.com.

Интерфейс localStorage – чрезвычайно полезная штука. Допустим, вы создаете Twitter-клиент и хотите, чтобы он мог делать следующее:

• Использоваться в вашем интернет-браузере для настольных компьютеров и на мобильном устройстве.

• Отображать в режиме онлайн сообщения с вашего последнего сеанса.

• В режиме офлайн ставить сообщения в очередь и отправлять их позже.

Рисунок 3.6. Инспектор хранилища в браузере Safari

С localStorage все это возможно. Пример ниже наглядно демонстрирует это. (Он чисто гипотетический, поэтому не обращайте внимание на мелочи.)

postTweet = function(tweetText) {

// Проверяем, в онлайне ли мы

if(navigator.onLine) {

// Привет, мы – онлайн! Отправь это сообщение, крошка!

} else {

// Хм, мы сейчас не в Сети. Лучше сохраните это для другого случая.

localStorage.setItem(“queue-” + +new Date(), tweetText)}

}

Несложно, правда? Чтобы увидеть все эти элементы в localStorage, мы должны повторить код и создать массив:

for (item in localStorage) { console.debug(item) }

Это выведет список всех ключей элементов, которые вы сохранили. Вы хотите вывести на экран твит, поставленный в очередь? Посмотрите, как это можно сделать:

for (item in localStorage) { console.debug(localStorage[item]) }

API localStorage и sessionStorage можно найти во всех современных браузерах (включая версию IE 8+). Итак, нет ни одной причины, мешающей вам создавать свои собственные приложения или просто начать экспериментировать с этим в клиентских приложениях.

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

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

Свойство font-stretch возможно имеет самое неудачное название в CSS.

Оно не расширяет шрифт искусственно, но взамен позволяет вам использовать растянутое и уплотненное начертание шрифта в гарнитуре. К примеру, если вы захотите использовать шрифт Helvetica Neue Condensed без свойства font-stretch, вам нужно будет подключить его как веб-шрифт (необходима лицензия) и обозначить его под другим именем в шрифтовом семействе. С font-stretch это делается проще:

Мы привыкли видеть текст в вебе выровненным по левому краю с рваным правым. При печати часто применяется выравнивание вместе с переносами, чтобы избежать «рек» в тексте (больших пробелов между словами и символами). Не так давно перенос был недоступен в Сети. Но сейчас все меняется. Свойство hyphens (перенос) доступно с префиксами в Safari (с версии 5.1) и Firefox, и в IE 10.

В примере ниже мы настроили выравнивание текста по всей ширине и автоматический перенос:

Рисунок 4.2. Пример параграфа с переносом (слева) и без переноса (справа)

p {

text-align: justify;

hyphens: auto;

…

}

Свойство auto указывает браузеру использовать словари переноса для разбивки слов в нужных местах, и вставлять переносы в конце строк. Каждому языку присущи свои словари переноса, поэтому поддержка этой функции будет варьироваться. Если вы вставляете свой собственный символ мягкого переноса (), это аннулирует автоматическое поведение браузера. Если вы хотите настроить перенос вручную, можете использовать ручной режим. Отключение переноса (по умолчанию) происходит через ключевое слово none.

Вот пример с переносом (слева) и без (справа). Обратите внимание на неровные интервалы между словами во второй и шестой строках текста без переносов.

В книгах и журналах текст обычно располагают несколькими колонками. Это делается для удобочитаемости. Длина строк остается короткой, при этом дизайнеры черпают полную выгоду от ширины страницы (или, в случае с Интернетом, от ширины окна браузера). Многоколоночная спецификация наделяет этой возможностью CSS. Это позволяет вам точно определить ряд атрибутов для колонок, такие как их количество, ширина и размер интервала между ними.

Доработаем пример выше с использованием колонок, чтобы попробовать, каково это.

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

Количество колонок может устанавливаться свойством column-count, которое допускает своей величиной целое число. Мы также применим такой интервал между колонками, чтобы они располагались красиво. В этом нам поможет свойство column-gap:

Часто бывает нужно, чтобы текст или элементы, такие как изображения, охватывали несколько колонок. Это можно достигнуть с помощью свойства column-span. В настоящее время можно все или ничего: вы можете либо охватить все колонки, используя значение all или не охватывать вообще, применяя значение none. Определить точное число охватываемых колонок невозможно. В нашем примере заголовки h3 охватывают полную ширину колонок[45].

h3 { column-span: all; }

Результат будет выглядеть примерно таким образом, как ниже на рисунке[46].

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

Рисунок 4.3. Верхняя колонка как при журнальной верстке. Текстовый блок в верхней части захватывает ширину нескольких колонок в нижней части

Пожалуй, самое сложное на сегодняшний день при работе с CSS – это разметка страницы. Что-то вроде простейшей центровки элемента на странице бывает ужасно сложно сделать. Вы можете поседеть (если не уже), когда верстаете двух– или трехколонный макет с равными по высоте колонками. Эти моменты сводятся к тому, что CSS на самом деле никогда не предоставлял способ разбивки страниц. Годами мы неправильно использовали формат, основанный на свойстве float, но это только один хак. Как таблицы, так и свойство floats, не разрабатывались для разметки страницы. Они создавались для обтекания изображения внутри текстового блока. А когда нам не хватает подходящих инструментов, мы импровизируем. Мы должны быть благодарны скромному свойству float за помощь нам все эти годы. Теперь с CSS3 мы можем попросить float подвинуться, потому что у нас есть новые инструменты для этого. Они из самых многообещающих – создание сетки с помощью тянущихся блоков.

Flexible Box Layout (или Flexbox) – это новая блочная модель, оптимизированная под дизайн интерфейса. Дети блока, настроенные для использования модели Flexbox, располагаются вдоль горизонтальных либо вертикальных осей. Их ширина увеличивается или сокращается для того, чтобы заполнять имеющееся пространство на основе назначенной гибкой длины.

Flexbox имеет историческое прошлое. Сначала оно представляло собой свойство для XUL Mozilla (расширенного языка пользовательского интерфейса) и переписывалось тысячи раз. Спецификация только сейчас достигает зрелости, а у нас есть довольно полная поддержка в WebKit и ночных сборках Chrome. Об этом, вне сомнения, полезно знать. Потому что спецификация, возможно, будет реализовываться быстро, если это уже не произошло до того, как вы об этом прочитали. В особенности с быстротой графика релизов Chrome и Firefox.

Расположить элемент по центру страницы, это, возможно, номер один среди всех запросов веб-дизайнеров. Он, пожалуй, даже превосходит запрос, как положить конец страданиям IE 6. С Flexbox это очень просто.

Начнем с основного шаблона HTML, с заголовка, который мы хотим разместить по центру:

Так как элемент body содержит заголовок, который мы хотим поставить по центру, мы задаем значение свойства display на flexbox:

Идем дальше. Мы хотим расположить наш элемент h1 по центру горизонтально. Раз плюнуть, скажете вы. Да, это, в общем-то, проще, чем «играть» с автоматическими отступами. Всего-то и надо дать команду Flexbox расположить по центру его элементы. По умолчанию элементы Flexbox распределятся горизонтально, поэтому установка свойства flex-pack выровняет элементы вдоль основной оси:

Рисунок 4.4. Простая горизонтальная и вертикальная центровка с использованием Flexbox

body {

display: flexbox;

flex-pack: center;

}

Другие возможные значения – это start (начало), end (конец) и justify (по всей ширине). Значение start выравнивает влево (или вправо, если текст идет справа налево), end выравнивает справа, а justify четко распределяет элементы вдоль оси.

Если вы хотите точно установить ось, вдоль которой выравнивается элемент, то можете сделать это с помощью свойства flex-flow. Стандартная настройка – горизонтальная, она даст нам тот же эффект, которого мы только что добились. Чтобы сделать выравнивание по вертикальной оси, мы можем использовать свойство flex-flow: column. Если мы добавим его в наш пример, вы заметите, что элемент лег по центру вертикально, но мы потеряли горизонтальную центровку. Реверсирование порядка при добавлении -reverse к значениям row или column также возможно (flex-flow: row-reverse или flex-flow: column-reverse), но в нашем примере это мало что значит, так как у нас всего один элемент.

Центровка по вертикали такая же простая, как и горизонтальная. Все, что нам надо, это применить подходящее свойство для выравнивания поперечной оси. Выравнивания чего?! По существу, поперечная ось – это неосновная ось. Поэтому если элементы Flexbox выравниваются горизонтально, то поперечная будет вертикальная, и наоборот. Мы делаем эти настройки с помощью свойства flex-align:

Если бы центровка элементов было все, на что способен Flexbox, это было бы чертовски здорово, но он может больше. Давайте посмотрим, как элементы Flexbox могут растягиваться и сжиматься, чтобы умещаться в имеющемся пространстве внутри блока Flexbox. Для этого рассмотрим другой пример, который можно посмотреть в браузере по ссылке smashed.by/flxbox2.

Рисунок 4.5. Интерактивное слайд шоу, созданное с использованием flex-order

HTML и CSS для этого примера идентичны предыдущему. Мы подключаем Flexbox и центрируем элементы на странице тем же способом. Вдобавок к этому, мы хотим сделать так, чтобы заголовок (внутри элемента header) не изменял свой размер. При этом пять блоков (элементы section) нам нужно подогнать по размеру, чтобы заполнить ширину окна. Для этого мы используем новую функцию flex как значение свойства width:

section {

/* чтобы сэкономить место, мы убрали остальной код */

flex: 1;

height: 250px;

}

То, что мы сейчас сделали, это заставили каждый элемент section стать равным одной единице flex. Так как мы не задали точную ширину, каждый из пяти блоков будет иметь равную. Элемент header примет установленную ширину (277 пикселей), так как он негибкий. Мы разделим оставшуюся внутри элемента body ширину на 5, чтобы рассчитать ширину каждого элемента section. Теперь если мы изменим размеры окна браузера, они или увеличатся, или уменьшатся.

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

Рисунок 4.6. Интерактивное слайд шоу, созданное с использованием Flexbox

section: hover {

flex: 2;

cursor: pointer;

}

Теперь имеющееся пространство делится на 6, а не на 5, и элемент, на который навели курсор, будет равняться двойной базовой величине. Обратите внимание, что элементу с двумя единицами flex не обязательно удваиваться по ширине, по сравнению с тем, у которого одна единица. Он становится вдвое больше, чтобы занять имеющееся пространство, которое добавлено к его «предпочтительной ширине». В наших примерах «предпочтительная ширина» равна 0 (по умолчанию).

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

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

Чтобы выбранный нами элемент переместился на первую позицию, нам просто надо задать меньшую цифру. Мы выбираем -1. Нам еще нужно задать заголовку -1 так, чтобы выбранный элемент не «выскочил» до него:

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

Взгляните на следующий стиль в двух разных размерах[47]:

Рисунок 4.7. Широкий вариант множественных фонов и градиентов

Рисунок 4.8. Узкий вариант

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

html {

background: #222;

min-height: 100 %;

}

body {

margin: 0;

}

section {

max-width: 25em;

margin: 0 auto;

padding-top: 150px;

color: white;

font: italic 100 %/1.5 ‘Palatino Linotype’, Georgia, serif;}

Но как добавлять звезды, силуэты на фоне неба и луну? Мы используем только два элемента (html и body – элемент section слишком узкий), а нам нужно четыре фоновых рисунка.

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

html {

background: url(“moon.png”) no-repeat 100 % 1em,

url(“stars.png”) repeat-x 0 0,

url(“city.png”) repeat-x bottom,

linear-gradient(black, #444);

background-color: #222;

min-height: 100 %;

}

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

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

html {

background: url(“moon.png”) no-repeat 100 % 1em,

url(“stars.png”) repeat-x 0 0,

url(“city.png”) repeat-x bottom;

background: url(“moon.png”) no-repeat 100 % 1em,

url(“stars.png”) repeat-x 0 0,

url(“city.png”) repeat-x bottom,

linear-gradient(black, #444);

background-color: #222;

min-height: 100 %;

}

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

html {

background: #222;

background: linear-gradient(black, #444);

height: 100 %;

}

body {

margin: 0;

background: url(“stars.png”) repeat-x 0 0;

background: url(“moon.png”) no-repeat 100 % 1em,

url(“stars.png”) repeat-x 0 0,

url(“city.png”) repeat-x bottom;

min-height: 100 %;

}

Намного лучше, и дает отдачу от возможностей каждого браузера.

Рисунок 4.9. Дизайн, который мы будем воспроизводить на CSS3

Допустим, нам поручено создать дизайн, отображаемый справа, с использованием CSS[48]. И опять мы уверены, что вы могли бы быстро сделать базовую разметку и, возможно, интегрировать несколько основ, которые вы знаете о системе цветопередачи RGBA и текстовых теней:

html {

min-height:100 %;

background: url(‘rainbow-wood.jpg’);

}

section {

max-width: 25em;

padding: 3em;

margin: 4em auto;

background: black url(logo.svg) no-repeat bottom right;

color: white;

font: bold 100 %/1.5 sans-serif;

text-shadow: 0 – .1em .2em black;

}

h1 {

margin-top: 0;

}

Результат близок к тому, которого мы добивались. Но есть проблемы:

• Фоновое изображение элемента html – гигантское. Это хорошо для огромных экранов, но, как правило, мы хотим подогнать размер под экраны поменьше.

• Розовый логотип слишком мал и прилеплен к правому нижнему углу без отступа от края.

• Нет розовой «строчки».

Разберем эти вопросы по порядку.

Рисунок 4.10. Результат после применения наших знаний о CSS2.1

CSS3 дает нам новое свойство для контроля размера фонового изображения: background-size. Это позволяет нам использовать одно и то же изображение в разных размерах. Мы можем либо установить точно определенный размер, либо применить один из двух ключевых слов для задания размера: contain и cover.

Для увеличения размера SVG логотипа мы снова используем свойство background-size, но на этот раз устанавливаем точный размер:

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

Давайте рассмотрим простой вариант предыдущего стиля, как показано ниже[49].

Рисунок 4.11. Полупрозрачная рамка с обрезанием фона

Для получения такого результата вы, вероятно, попробуете что-то подобное:

html {

min-height: 100 %;

background: url(‘rainbow-wood.jpg’) top;

background-size: cover;

}

section {

max-width: 20em;

padding: 3em;

margin: 4em auto;

border: 20px solid rgba(0,0,0,5);

background-color: black;

color: white;

font: 100 %/1.5 sans-serif;

text-shadow: 0 – .1em .2em black; }

h1 {

margin-top: 0;

}

Рисунок 4.12. На самом деле наша граница не полупрозрачная. Почему?

Но когда вы попробуете, то увидите, что граница по факту не полупрозрачная. Почему так произошло? Причина в том, что по умолчанию фон также растягивается по границе. Вспомните все те разы, когда вы применяли стили рамки с пробелами (т. е. точечные, пунктирные и удвоенные) в дни существования CSS2.1? Это то же самое, но только сейчас у нас есть средства контроля поведения, а именно свойство background-clip. Его значение по умолчанию – border-box, результат которого аналогичен предыдущему опыту. Но мы должны изменить его на padding-box:

background-clip: padding-box;

Это заставит фон обрезаться точно там, где нам надо.

Как насчет этого стиля[50]? Как вы справитесь с зигзагообразной рамкой? Наверное, вы начнете применять установленную ширину и высоту, и огромных размеров фоновое изображение со значением no-repeat. Если средство отображения установило размер шрифта больше, чем по умолчанию в браузере, или у него нет шрифта, близкого к тому, что вы собираетесь задать, текст растечется над установленным фоновым изображением.

Рисунок 4.13. Пример рамки

Рисунок 4.14. Изображение cloth.svg, с которым мы и будем работать

Свойство border-image – новое и мощное, дает нам возможность использовать одно маленькое изображение и для фона, и для рамки элемента. Мы определяем, каков его масштаб и как оно повторяется. Они должно отличаться для каждого края. В этом примере мы использовали рис. 4.14.

А вот код CSS, который идет для него:

html {

min-height:100 %;

background: white url(background.jpg);

}

section {

max-width: 20em;

padding: 3em;

margin: 4em auto;

border: 20px solid transparent;

– webkit-border-image: url(cloth.svg) 33.33 % round;

– moz-border-image: url(cloth.png) 33.33 % round;

– o-border-image: url(cloth.svg) 33.33 % round;

border-image: url(cloth.svg) 33.33 % round fill;

font: 100 %/1.5 sans-serif;

text-shadow: 0 1px white;

}

h1 {

margin-top: 0

}

Свойство border-image определяет, какое изображение будет использовано, какой должна быть ширина каждого «кусочка» (в этом случае мы хотим разрезать по три части, как горизонтально, так и вертикально, это лишь одна цифра) и как эти «кусочки» должны повторяться или растягиваться (ключевое слово round повторяет рисунок и масштабирует его так, чтобы на стороне элемента оказалось целое число изображений.). Ключевое слово fill сохраняет средний кусочек в виде фона, но оно не поддерживается браузерными префиксами. К счастью, у свойств с браузерными префиксами это поведение есть по умолчанию. Вы также можете заметить, что мы используем SVG (масштабируемую векторную графику) в каждом браузере, кроме Firefox. Дело в том, что в момент написания этого раздела Firefox «глючит» при применении SVG-картинок для рамок. Но Mozilla работает над этим. Хотите, проверьте сами.

Когда мы используем свойство border-image, стиль и цвет рамки, который мы определяем, игнорируется до тех пор, пока стиль рамки не устанавливается до значения none. Только свойство border-width имеет эффект. Но мы хотим задать что-то вроде solid transparent, так чтобы когда border-image не поддерживается, у нас не было бы уродливо-толстой рамки. Вы можете варьировать расстояние, а в некоторых случаях «реальный» запасной вариант рамки лучше, чем ничего.

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

Мы создадим простую галерею рисунков, чтобы продемонстрировать применение некоторых трансформаций. Наведение курсора и клик по нему запустит различные трансформации. Можете посмотреть пример, пройдя по ссылке smashed.by/trnsfrms.

В примере каждый рисунок включен в элемент figure, как здесь:

<figure>

<img src=”2473924153_d5e91e5fa2_z.jpg” alt =”” />

</figure>

<! – повторяющийся тег figure для каждого изображения->

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

figure {

float: left;

z-index: 1;

margin: 1rem;

width: 160px;

height: 160px;

transition-duration: 1s;

transform: scale(0.25);

}

Свойство transform допускает в качестве значения разделенный пробелами список функций трансформирования. Здесь мы используем функцию scale для уменьшения размера элемента вчетверо. Масштабирование пойдет от центра элемента по умолчанию. Значения меньше 1 уменьшат масштаб элемента, а значения выше этой цифры – увеличат.

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

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

Рисунок 4.15. Простая галерея изображений без трансформаций

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

figure: hover {

transform: scale(0.33) rotate(2deg);

z-index: 100;

cursor: pointer;

}

Здесь мы применяем два преобразования. Любое количество трансформаций может применяться при задании их через список, разделенный пробелами. Здесь мы уменьшаем масштаб рисунка в 3 раза, затем поворачиваем его на 2 градуса. Функция rotate перемещает элемент вокруг оси по часовой стрелке. Чтобы перемещение было против часовой стрелки, мы используем отрицательную величину:

figure: nth-of-type(even):hover {

transform: scale(0.33) rotate(-2deg);

}

Рисунок 4.16. Преобразование, применяемое для изображения по наведению курсора с использованием CSS3

Каждая функция transform применяется по очереди, поэтому элемент сначала масштабируется, а потом вращается. Помните, что это важно! Порядок влияет на размер элементов при изменении масштаба, и на направление каждой оси при повороте.

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

figure: hover + figure {

transform: scale(0.25) rotate(-1deg) translateX(15px);

transition-duration: 1.5s;

transition-delay: .2s;

}

Вы видите, что нет строгого движения вдоль оси X или преобразования на 15 пикселей, потому что преобразование scale уменьшает длину на четверть, а преобразование rotate поворачивает ось X на 1 градус против часовой стрелки.

Функция translateX принимает одно значение, используя действующую длину элемента. Также существует соответствующая функция translateY. Они обе могут устанавливаться вместе с использованием функции translate, которая допускает две величины (сначала X, затем Y), которые разделяются запятой.

Последнее семейство функций transform – это skewX, skewY и skew. Они определяются так же, как и функции transform, но они перекручивают элемент по одной или двум осям. Обычно это происходит с использованием моделируемой трехмерной перспективы.

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

Разработчики считают селекторы CSS часто чуть ли не самой прикольной игровой площадкой, на которой можно развернуться. Вы можете подумать, что нам на самом деле не нужны дополнительные селекторы для обращения к элементу в разметке. Или, может быть, вы из последних сил воюете с ненавистными искусственными приемами jQuery, чтобы перезаписать значения CSS по умолчанию в определенных ситуациях. И в том, и в другом случаях с селекторами CSS3 вы получите удовольствие. Давайте посмотрим, какие возможности у нас есть сейчас, когда селекторы CSS3 набирают поддержку в браузерах.

Давайте вспомним пример с вертикальным ритмом из раздела о типографике. Вы, возможно, в курсе, что можете ссылаться на определенные разделы страницы, используя идентификатор с решеткой после указателя URL. Так мы можем использовать что-то вроде этого http://example.com/index.html#def для ссылки на раздел с определениями типографики. Когда на странице несколько больших разделов, пользователю сразу же видно, в какой раздел он попал.

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

В прошлом для выполнения этой операции нам бы понадобился язык JavaScript. CSS3 дает нам новый псевдокласс для указания текущего элемента, т. е. элемент, чей ID-атрибут совпадает с текущим хешем в URL. Этот псевдокласс называется: target.

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

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

В CSS 2.1 у нас был только один структурный псевдокласс: first-child. CSS3 расширяет это и дает нам изобилие новых псевдоклассов, что решает не только перечисленные задачи, но и другие вопросы:

• nth-child

• last-child

• nth-last-child

• only-child

• first-of-type

• nth-of-type

• last-of-type

• nth-last-of-type

• only-of-type

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

Наиболее популярный на данный момент – это Selectivizr[52].

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

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

Для того чтобы продемонстрировать, как использовать перемещения, мы собираемся провести день на скачках. Помните тот автомат со скачущими лошадками, когда вы были маленькими? Если нет, не расстраивайтесь. Идея проста: лошадки скачут по дороге с разными скоростями, а вы должны угадать какая из них придет первая. Эта игра переделана при помощи перемещений CSS. Вы можете поиграть дома, пройдя по ссылке smashed.by/trnsxpl. Просто наведите курсор на дорожки и смотрите, как скачут лошадки!

Рисунок 4.20. Игра со скачущими лошадками, созданная при помощи перемещений CSS

Разметка для дорожки такова:

<div id=”track”>

<h1>The<em>Smashing</em> Derby</h1>

<ol>

<li><div></div></li>

<! – добавленные лошадки ->

</ol>

</div>

Каждый тег li представляет беговую дорожку, а тег div внутри содержит лошадь. Затем мы перемещаем ширину div по наведению курсора и задаем время:

#track div {

width: 3em;

height: 3em;

background: url(horse.png) no-repeat right center;

transition-property: width;

transition-duration: 6s;

}

#track: hover div {

width: 40em;

}

Здесь мы говорим, что свойство width должно перемещаться около 6 секунд от 3 ems до 40 ems, когда на дорожку наведен курсор. Свойство transition-property настраивается по умолчанию ко всему, поэтому если вы не установите его точно, оно будет перемещать каждое анимируемое свойство.

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

Скачки не были бы такими забавными, если бы лошади все время неслись с одной скоростью и приходили к финишу одновременно. Что ж, давайте настроим скорость каждой лошадки с помощью свойства transition-timing-function. У всех видов функций расчета времени одинаковая продолжительность до завершения, но их ускорение и замедление происходит на разном уровне, в зависимости от установленной кривой Безье. Не волнуйтесь, если это звучит слишком по-математически: вы можете выбирать из набора встроенных функций расчета времени. Эти предустановки имеют следующие значения ключевых слов:

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

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

Взаимодействие CSS перемещений, трансформаций и анимаций с JavaScript – мощный инструмент, и нам следует использовать его гораздо больше. Сейчас, похоже, идет битва между теми, кто везде применяет jQuery или JavaScript, и теми, кто работает исключительно с CSS. Это не помогает нашим пользователям, а нас тормозит с написанием лаконичных, эффективных решений. Хороший веб-разработчик почерпнет достоинства из всех технологий, а не будет приверженцем какой-то определенной. Много ума не надо, чтобы использовать одну технологию на все случаи жизни. А потом оставить продукт работать только в одном браузере или на одном устройстве.

Если вам нужно, чтобы все необходимые свойства поддерживались в старых браузерах, используйте библиотеку, такую как jQuery. Вы также можете найти «заплаты» для старых браузеров в форме полифилов. А вообще, давайте уже прекратим пытаться заставить устаревшие технологии поддерживать то, чтомы создаем для новых. Никто не перестанет использовать продукт только из-за того, что браузер IE 6 не делает плавных перемещений из одного состояния в другое. А это и есть самое важное свойство хорошего веб-продукта.

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

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

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

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

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

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

Только после того как реальные люди начнут пользоваться вашим продуктом, вы узнаете, на правильном ли вы пути в разработке своего решения и набора функций. МэтМуленвег, разработчик – основатель системы управления контентом WordPress, проводит прекрасную аналогию между использованием и кислородом: «Вы никогда не сможете до конца предугадать, как аудитория отреагирует на то, что вы создадите, пока это будет оставаться за кадром. Это значит, что все, над чем вы работаете и не выпускаете в свет, просто умрет как от нехватки кислорода». Этот раздел представит ряд техник, которые помогут вам вызвать первоначальный интерес к продукту и создать непрерывный процесс регистрации после его выпуска.

Рисунок 6.1. Страница «Скоро открытие» сервиса SquidChef

Первое, что нужно для любого большого продукта, это пользователи. И вы можете привлечь их еще до запуска своего детища, и даже до начала его создания. Возможно, вы знакомы со страницей Coming soon («Скоро открытие/запуск»). Она разработана для продвижения нового продукта или услуг, которые должны быть вскоре выпущены. На странице высвечиваются характеристики и преимущества продукта, запрашивается ваш e-mail на случай, если вы захотите получить уведомление о его выпуске.

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

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

Вот один из способов, как сделать так, чтобы целевая страница не просто собирала лиды, но и предоставляла вам ценную информацию о тех функциях, на которых следует сфокусироваться. Monotask применил эту умную технику на своей coming-soon странице. Если кого-то интересует продукт, то он оставляет свой е-мейл, чтобы попасть в список рассылки, уведомляющей о запуске продукта. При этом появляется краткий опросник под названием «Помогите нам создать, то, что вы хотите!» В опроснике заложено несколько вопросов о том, каким образом сейчас пользователь решает проблему, и сколько он готов заплатить за приложение.

Рисунок 6.2. Форма, собирающая е-mail на странице Monotask

Сокрытие опросника за формой собирающей e-mail преследует две цели. Во-первых, первоначальное побуждение к действию должно быть простым и ясным. Все, что нужно сделать пользователю, – это дать свой e-mail-адрес. Демонстрация формы сразу же могла бы отвлечь от этого действия.

Рисунок 6.3. После подтверждения вашего e-mail-адреса показывается краткий опросник

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

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

Существует UX-миф о том, что вы должны представлять ссылку на регистрацию или саму форму регистрации сразу же, т. е. вверху целевой страницы. Логика этого мифа исходит из идеи об устранении возможных препятствий из процесса регистрации. Однако в этой логике есть изъян, и кроется он в самом определении препятствия – в данном случае это все, что не является регистрацией.

Регистрационная форма – это не единственное, что нужно заполнить посетителям. Да, конечно, ссылка на нее и она сама важны для процесса, но прежде, чем люди начнут вводить информацию, должны произойти еще две вещи. Во-первых, посетители должны четко знать, что им дает регистрация. Во-вторых, они должны этого захотеть. Здесь не помешает хороший копирайтинг.

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

Например, когда компания ZURB создавала домашнюю страницу для одного своего заказчика и перенесла кнопку регистрации вниз страницы, обнаружилось, что конверсия увеличились на 350 %[64] – неслабое улучшение. У Vendio регистрационная форма стояла первой позицией на одной из страниц, сместив текст вниз. При переделке дизайна форму перенесли на отдельную страницу, а ссылку на нее оставили надомашней. Что в итоге?

Конверсия поднялись на 60 %[65].

Рисунок 6.4. Сайт Vendio с формой регистрации прямо на главной странице (исходная версия)

Рисунок 6.5. Сайт Vendio с регистрационной формой, перенесенной на отдельную страницу (финальная версия)

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

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

Например, когда Twitter переделывал свою регистрационную форму, то ввел дополнительный шаг в процесс. Теперь на первом шаге Twitter пытается подключиться к e-mail-адресу посетителя для поиска друзей, которые уже пользуются Twitter. Если пользователь не хочет показывать контакты своей почты, то он окажется прямиком на пустой странице профиля – не самое лучшее начало.

Также добавился еще один шаг с предложениями. Сейчас пользователь может выбирать темы, которые ему интересны. А Twitter предлагает популярные аккаунты, на которые можно подписаться. Итак, даже если пользователь не найдет друзей, то узнает об интересных людях, а новый профиль сразу же покажет, о чем они «щебечут».

Редизайн сработал? Да: конверсия выросла на 29 %[66].

Рисунок 6.6. Twitter помогает вам найти людей для подписки на их ленты в процессе регистрации

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

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

Рисунок 6.7. Регистрационная форма сервиса Stripe позволяет вам «пропустить этот шаг»

Рисунок 6.8. Вы можете сразу, без регистрации, «перескочить» на рабочий экран Stripe. Верхняя ссылка «Save account» («Сохранить учетную запись») позволит вам зарегистрироваться позже

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

Рисунок 6.9. Регистрационная форма Facebook с подтверждением адреса e-mail

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

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

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

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

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

Формы-аккордеоны состоят из нескольких разделов, каждый со своим подзаголовком. Все они располагаются на одной странице. Раздел, который пользователи заполняют, они видят. Остальные остаются скрытыми, показываются только их заголовки. Когда пользователь готов перейти к следующему разделу, он раскрывается, а остальные сворачиваются, отсюда и название.

Рисунок 6.10. Компания Apple использует форму-аккордеон на их сайте для онлайн-покупки. Обратите внимание, что кнопка «Continue» («Продолжить») находится внутри каждого блока, а не внизу страницы

Насколько хорошо работает эта техника на практике? Etre, компания из Лондона, занимающаяся юзабилити, провела тестирование форм-аккордеонов[67]. В нем приняли участие 24 простых пользователя в возрасте от 19 до 48 лет, с обычным опытом покупок через Интернет. Тестировались два варианта формы: с формой на нескольких страницах и с одной страницей, где все поля формы находится вместе. Один из вариантов предлагал пользователям нажать на следующий заголовок для того, чтобы развернуть его. В другом располагалась кнопка в конце каждого раздела.

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

Это значит, что если ваш контент чувствителен ко времени, например если вы проводите аукцион, то форма-аккордеон может стать лучшим выбором.

Лучшим вариантом формы-аккордеона, заполняемой в процессе тестирования компанией Etre, стала та, где клавиша расположена внизу каждого раздела, а не та, в которой нужно нажимать на заголовок, чтобы развернуть раздел.

Когда люди заполняют формы, они ищут кнопку «Подтвердить».

А активизируемые мышью заголовки слишком далеки от привычек и ожиданий пользователей. Поэтому, если вы используете форму-аккордеон, убедитесь, что кнопка «Подтвердить» стоит внизу каждого раздела.

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

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

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

Рисунок 6.11. Гендерный вопрос в регистрационной форме Bagcheck

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

Рисунок 6.12. Etsy пытается догадаться о вашем местонахождении на основании языковых настроек вашей системы

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

Использование стандартных настроек таким способом действенно не везде. Например, при добавлении нового события в календарь, вы на самом деле хотите увидеть пустую форму, потому что все события разные. С другой стороны, если есть шаблон, то «умные» настройки по умолчанию могут стать хорошим способом упростить взаимодействие с пользователями.

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

Контекст может изменить значение слов. Институт Baymard провел исследование по удобству пользования и выяснилось, что слово «continue» («продолжить») в интерфейсе онлайн-магазинов сбивало с толку трех из десяти испытуемых[68].

Почему так произошло? Все дело в контексте. Для тех, кто добавил товарв свою корзину и хочет перейти к заказу, «continue» означает «continue to checkout» («перейдите к заказу»). Для остальных, кто собирается выбрать еще другие товары, то же самое слово означает «продолжить выбор покупки». Всегда поясняйте значение надписи, если оно привязано к контексту.

Так, вместо «continue» используйте более описательное выражение, как «continueshopping» («продолжить покупку») или «continuetocheckout»(«перейти к оформлению заказа»). Ясность лучше краткости.

Рисунок 6.13. Amazon использует кнопку Proceedtocheckout («Оформить заказ»)

Вот другой пример. У HubSpot была надпись на экране настроек домена: «Add domain»(«Добавить домен») – что приводило в замешательство. Разработчики HubSpot имели в виду то, что клиенты могли пользоваться этим интерфейсом для добавления существующего домена к их учетной записи. А пользователи думали, что программа просит их создать новый домен, то, чего они не хотели делать, потому что у них уже был один.

Глагол «add» («добавить») сбивал всех с толку. HubSpot изменили надпись на «Connectyourdomain» («Подключите ваш домен») – и инцидент был исчерпан.

Рисунок 6.14. На сайте Target опускают глагол и просто используют слово «checkout» («оформление заказа»)

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

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

В зависимости от того, данные какой карты вы заполняете (VISA, Master-Card и т. д.), используя приложение Square, иконка меняет свое изображение. Когда номер карты введен, все цифры, кроме последних четырех, исчезают. Потом иконка карты перевернется и подсветится область, где вы сможете ввести код проверки подлинности карты (CVV).

У Square очень много таких фишек. Когда вводите номер AmericanExpress, группировка цифр изменяется от 4 до 4, 6 и 5, отображая числовую структуру на карте, который вы пользуетесь. Так как CVV у AmericanExpress находится впереди, иконка карты не будет переворачиваться, а вместо этого покажет вам, где его найти на карте. Если вы вводите некорректное количество цифр кода, поле «вздрогнет» и станет красным. Это означает, что вы ошиблись. Также невозможно введение неправильного срока действия. Интерфейс просто не позволит вам этого сделать. Такое внимание к деталям приходится по душе клиентам. Это помогает им правильно заполнить форму и подсказывает направление, если затрудняются или ошиблись. Также берутся во внимание различные случаи использования, например расположение кода CVV на определенной карте может быть спереди, а не сзади.

Рисунок 6.15. Square скрывает полный номер карты и подсвечивает местонахождение CVV в иконке

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

Эта цитата Стива Джобса хорошо созвучна со знаменитым высказыванием Генри Форда: «Если бы я спросил клиентов, чего они хотят, они бы ответили: более быструю лошадь». Инновации происходят, когда вы пробуете новое, а не зацикливаетесь на старых способах решения проблем. Распространенные дизайны шаблонов и практический опыт показывают нам, что работает хорошо, но они не учат нас тому, как создать что-то лучшее. Слепое применение шаблонов, конечно, обеспечит вам получение надежного продукта. Но с другой стороны, вы будете плестись в хвосте тех компаний и дизайнеров, которые внедряют новаторские идеи в поисках лучших решений.

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

Рисунок 6.16. Эксперимент Apple со стилем кнопок представлен в виде селектора, похожего на слайдер

Рисунок 6.17. В конечном итоге Apple возвращается к более простому решению, с кнопками, похожими на кнопки, явно выделенному текущему пункту

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

Однако это не сработало. Многие пользователи не восприняли это изменение на ура[69], и Apple вернулась к прежнему дизайну, в котором кнопки реально выглядели как кнопки, а «утапливалась» выбранная в данный момент. Несмотря ни на что, эксперимент не провалился. Дизайнеры получили ценную информацию о том, какой сценарий лучше работает, и в конечном итоге было оставлено оптимальное решение. Если что-то идет вразрез с общепринятыми шаблонами, но помогает лучше решить проблему, то этот способ неизбежно станет рекомендуемым.

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

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

Когда NerdCommunications разрабатывал приложение «Ben the Bodyguard» («Бен-телохранитель»), то сделал сайт в виде интерактивной истории. Мы видим опускающуюся на город тьму и таящие угрозу улицы. В центре приложения представлен герой – Бен-телохранитель. Когда вы прокручиваете страницу вниз, он начинает двигаться с вами, а если вы прокрутите дальше, он раскроет идею приложения и то, для чего это вам нужно. Создателям приложения удалось преобразовать ваш обычный маркированный список характеристик и преимуществ в интерактивные и захватывающие впечатления.

«Spent», сайт добровольных пожертвований Городского министерства Дарема, тоже демонстрирует это. Просить пожертвования нелегко, так почему бы не превратить этот процесс в игру? «Spent»– это веб-игра, в которой вы исполняете роль обычного безработного американца. Перед вами стоит задача – прожить один месяц без денег. В процессе вы должны искать работу, смотреть за детьми и пережить множество небольших кризисов. Успешным исходом считается заставить играющего проникнуться безработными и сделать пожертвования в конце игры.

Рисунок 6.18. Бен-телохранитель сопроводит вас на интерактивной прогулке по Злым улицам

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

Рисунок 6.19. Дойдите до конца игры в «Spent». Без денег в течение месяца

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

Например, у компании Klout из Сан-Франциско измеритель завершенности находится под заголовком «Connect» («Подключиться»). Это список дел в виде обычного текста, который предлагает вам выполнить различные действия, такие как подключить вашу учетную запись на Klout к сетям Twitter или Facebook, следовать за Klout в Twitter, поделиться вашими показателями на Klout и т. д. Как только вы выполняете какое-то действие, оно вычеркивается из списка. Другим примером может служить Groupon (американский сервис коллективных скидок). Его измеритель завершенности в боковой колонке – это список действий, такой же как у Klout, но с индикатором выполнения вверху, который заполняется по мере вычеркивания позиций. Почему это работает? Здесь на кону два психологических фактора. Во-первых, любопытство. Людям интересно узнать, что произойдет, когда измеритель достигнет 100 %. Будет ли какая-то награда в конце? Второй фактор – это цепочка обратной связи. Когда пользователь выполняет задачу, она отмечается, и показания измерителя растут. Так устанавливается четкая цель, и пользователи получают указания, что делать дальше.

Рисунок 6.20. Измеритель завершенности Klout приглашает пользователей быть активнее и вычеркнуть пункты из списка дел

Обновление в режиме реального времени всегда было возможным, но сегодня новые технологии еще больше упрощают этот процесс. WebSockets (веб-сокеты) – свойство HTML5, которое позволит вам поддерживать интерактивный сеанс связи на сервере без его запроса и ожидания ответа через каждые несколько секунд. В действительности это намного упрощает работу в режиме реального времени, которая идет быстрее, а ваш сервер при этом не наводняется запросами.

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

Рисунок 6.21. Уведомления в режиме реального времени в Bagcheck

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

Веб-сокеты открывают новые грани для экспериментов с веб-приложениями и сайтами. Аналитика и игры в реальном времени – это явное использование, но, как показывает Bagcheck, режим реального времени может применяться также к элементам интерфейса, которые мы привыкли расценивать как статические, таким как список комментариев.

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

Селекторы страныпредставляют собой выпадающее меню, открывающее на странице длинный список стран, который вы будете прокручивать, чтобы выбрать нужную вам. Можем ли мы придумать что-то получше? Да. Кристиану Холсту и Джейми Эплсиду из института Baymard удалось переделать селектор страны, чтобы сделать процесс более удобным[70]. Идея такова – использовать живое поисковое поле для выбора страны. Так если пользователь начинает печатать название, включается поиск и выпадает список совпадений. Верхний вариант будет выделен, поэтому пользователь просто должен нажать клавишу Enter, и этот вариант окажется в поле. Пользователь уже знает, чего он хочет, поэтому впечатывание первых букв из названия страны намного быстрее, чем прокручивать список, в котором может стоять тысяча позиций.

Рисуок 6.22. Селектор страны в действии

Эта реализация работает, так как она решает три основных проблемы. Во-первых, вы должны учитывать опечатки и последовательность; пользователь может печатать слова в неправильном порядке или неверно по буквам. Во-вторых, некоторые страны имеют не одно название. Например, Нидерланды – это Голландия. Поэтому люди, которые пишут «Голландия», должны быть уверены, что получат правильное сочетание. То же касается и Америки, когда это название пишут вместо Соединенных Штатов.

И, наконец, некоторые страны более распространены среди ваших пользователей. Поэтому, если кто-то начинает впечатывать «United» (Соединенный, объединенный), первым сочетанием лучше сделать «United States»(Соединенные Штаты), а не «United Arab Emirates» (Объединенные Арабские Эмираты). Если только, конечно, большинство ваших пользователей не из ОАЭ.

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

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

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

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

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

Рисунок 6.23. Введение вашего имени на странице авторизации запускает поиск пользователей на сайте Bagcheck

Рисунок 6.24. Как только вы найдете свою учетную запись, вы увидите опции, которые можете использовать при авторизации

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

Когда компания 37signals приступила к разработке мобильной версии своего приложения управления проектами Basecamp, она пыталась найти пути решения этих проблем и создать интерфейс, который превзошел бы исходный вариант. Для управления касаниями 37signals убедилась, что все элементы имеют состояние «выбрано». Так, чтобы при прикосновении клавиша немедленно подсвечивалась, и пользователь мог узнать, что его выбор зарегистрирован, и он нажал верно.

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

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

Рисунок 6.25. Если начальная загрузка длится дольше положенного, появится сообщение, которое известит вас о том, что приложение все еще работает (грузится)

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

Рисунок 6.26. Скромная вращающаяся пиктограмма в правом верхнем углу, которая говорит пользователю о том, что приложение проверяет обновления на сервере

Другой пример – шведский магазин обуви Heppo.se. Здесь вы снова видите выпадающее меню, где представлены различные модели туфлей и сапог, которые вы можете купить.

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

Рисунок 6.27. Селектор Bonlook для очков

Рисунок 6.28. Heppo.se показывает пиктограммы каждой модели обуви, которую они продают

Тони Шей создал электронному магазину Zappos историю успеха. С момента его присоединения в 2000 году к Zappos в роли исполнительного директора, годовой доход компании ежегодно удваивается. В 2009 году он достиг миллиарда долларов. Zappos – это обувной онлайн-магазин. Но самое интересное то, что Шея совсем не интересовала обувь. Что его на самом деле привлекало – так это работа с клиентами, а страсть к созданию у них сильных впечатлений принесла реальный успех компании.

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

Все это вносит вклад в общую картину, а гарантия того, что все будет хорошо, делает ваших клиентов счастливыми.

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

Как повысить качество поддержки, которую предоставляет компания, с помощью визуализации? 37signals разработала рейтинговую систему, когда в конце каждого обращения по электронной почте люди оценивают поддержку, которую они получили. Рейтинговая система имеет три ссылки: одна для «great» («отлично»), другая для «just OK» («хорошо») и последняя «not so good» («не очень хорошо»). Каждая оценка сопровождается смайликом, для того чтобы выбор можно было сделать быстрее. Смайлики раскрашены под цвета светофора: зеленый для «отлично», желтый для «хорошо» и красный для «плохо».

Рисунок 6.29. 37signals представляет оценки своей службы поддержки на «Страничке смайликов»

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

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

37signals также использует эту систему как мощное орудие маркетинга.

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

Документация часто является слабым звеном во впечатлениях пользователя. На самом деле писать неувлекательно и читать незанимательно. Но так не должно быть. Команда MailChimp (сервис e-mail-рассылок) разработала отличный способсоздания документации. Сначала даются основы, описываются основные функции. Потом каждый раз при получении запроса о поддержке компания отписывает основательные, детальные ответы. После отправки ответа клиенту MailChimp сохраняет его в базе знаний. Таким образом, потребитель получает отличный сервис, а затраченное время также идет на создание исчерпывающего ресурса базы знаний, которым он (потребитель) может пользоваться.

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

Однако будьте осторожны! Шутки проходят только тогда, когда читатели их воспринимают. При устранении серьезных проблем читатель, скорее всего, будет напряжен, и юмор на подобных страницах едва ли уместен.

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

Рисунок 6.30. Картинка со страницы справки о временных зонах

Райан Карсон на ThinkVitamin ратует за предоставление кредита пользователям, когда что-то идет не так. Если пользователи сталкиваются с какой-то проблемой на сервере, Райан компенсирует им убытки кредитованием их аккаунта (например, предлагает период бесплатной подписки). Это необычное решение проблемы. Клиенту показывают, что если что-то пойдет не так, ThinkVitamin возьмет на себя полную ответственность. Такая тактика отлично работает в пользу ThinkVitamin. Люди не привыкли к всеобъемлющему клиентскому сервису. Поэтому когда они соприкоснутся с этим, их благодарность не будет знать предела. И не только. Они также захотят поделиться своими впечатлениями. Предоставляя клиенту больше того, за что он заплатил, и вы приобретете больше, чем потеряете, и к тому же сделаете людей счастливее, терпимее. Они будут готовы рекомендовать ваш сервис всем друзьям.

Любое взаимодействие с вашими клиентами – это возможность для всестороннего контакта, укрепляющего ваши взаимоотношения. Удивительно, но многие компании сегодня все еще пользуются «безответными» почтовыми адресами (no-reply@sitename.com). Но, в конце концов, лучше показать вашим клиентам, что вас волнует их мнение, чем сказать о том, что им не нужно отвечать вам, так ведь?

Однако дела обстоят намного хуже. «Безответные» e-mail-адреса могут негативно отразиться на показателе доставки писем. Например, Google’s Priority Inbox мониторит адреса, на которые отвечает большинство людей, и отмечает их как важные. Вполне вероятно, что их спам-алгоритм также учитывает ответы. Ведь если вы шлете ответ на почту, скорее всего, адрес подлинный, и это не спам.

Что же делать? А вот что! Превратите проблемный адрес «no-reply» («не отвечать») в «please-reply» («пожалуйста, ответьте»). Если у вас есть система техподдержки пользователей, вы можете переправлять ответы, которые получаете, туда. А потом обрабатывать их как обычно.

Рисунок 6.31. Современная система управления платежами обычно имеет опцию выдачи кредита на активный клиентский счет. Представленный пример – кредитная страница платежного сервиса Recurly

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

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

Рисунок 6.32. Компания Dropbox нашла способы простого обращения к людям через почту и соцсети

Раньше Dropbox оплачивала рекламу[71], но потом пришла к выводу, что слишком много денег тратится на привлечение клиентов, а вложения не возвращаются в доход. Компания пересмотрела свою стратегию и сосредоточилась намаркетинге, ориентированном на пользователя (customer-drivenmarketing). Новый подход заключался в поощрении преданных клиентов за рекомендации продукта своим друзьям. Dropbox стимулировал обе стороны: рекомендатели получали дополнительное бесплатное хранилище, а их друзья – большее пространство памяти, чем могли бы иметь.

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

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

Рисунок 6.33. Благодарственная открытка от Wufoo

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

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

Как мы говорили, некоторые устройства уже имеют дисплей с высокой пиксельной плотностью. И мы видим, что выпускаются мобильные устройства с еще более высоким PPI. Весьма вероятно, что мы увидим настольные ПК и лэптопы с высоким PPI[73] –Windows, Mac OS X и Сеть в целом будут следовать одной тенденции – мобильности.

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

Для разработки под iOS компания Apple подобрала две дисплейные плотности и поэтому два масштаба пользовательского интерфейса (UI). Новейшие дисплеи имеют в точности удвоенное пиксельное разрешение от устройств раннего поколения. Для iPhone его значение163 PPI для ранее выпущенных моделей. А для дисплеев iPhone 4 Retina и последующих моделей – это 326 PPI.

Для масштабирования это идеальное решение, потому что все, что создано с правильными техниками для малого размера, будет отлично масштабироваться на дисплее Retina. Однако вам понадобятся два полных комплекта изображений: один для дисплеев не-Retina, другой для дисплеев Retina. Apple добавляет @2x к названиям файлов с изображениями для дисплеев Retina. Поэтому myimage.png должно выглядеть как myimage@2x.png.

Таким образом, если ваши первоначальные файлы не для размеров дисплея Retina, то Retina они должны быть отмасштабированы до 200 %.

Операционная система Android схожа с iOS, за исключением того, что она имеет четыре пиксельных плотности вместо двух. Это потому что Android используется в огромном спектре устройств. Android представляет следующие разрешения:

• 120 PPI (низкая плотность),

• 160 PPI (средняя плотность,

• 240 PPI (высокая плотность),

• 320 PPI (сверхвысокая плотность).

Подобно системе Android, Windows Metro была разработана для размещения в широком спектре устройств, так что здесь тоже понадобится большое количество изображений. Исходники для Windows Metro создаются под 100, 140 и 180 %, если только не используется масштабируемая векторная графика (формат SVG).

Хотя и непровозглашенная, система MacOS X очень похожа на модель для iOS и работает с дисплеями не-Retina и Retina с настройками изображений в 100 и 200 %. Где это уместно, можно использовать для интерфейсных элементов Mac Os X PDF изображения, где в одном файле находятся два размера.

Немного неясно, как будут обрабатываться дисплейные пиксельные плотности в вебе в дальнейшем, но применяемые методы, скорее всего, будут очень похожи на методы iOS, Android, Windows Metro и других «родных» платформ.

Некоторые сайты уже включают множество изображений, базирующихся на PPI дисплее, похожем на iOS, Android и Windows Metro. Другие дизайнеры пытаются рисовать все с помощью кода, используя CSS и SVG изображения или встраивая пиктограммы и глифы в шрифтах, поэтому и наборы изображений не требуется.

Рисунок 7.4. Избегайте растровых изображений и всегда используйте векторные формы и эффекты

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

Когда дело дойдет до создания элементов, которые легко масштабировать в Photoshop, избегайте растровых изображений. Растровые изображения по своей природе – это сетки с квадратными элементами изображения (пикселями). Это означает, что нельзя добавлять детали, когда растровое изображение расширяется, потому что дополнительных деталей нет (дополнительные пиксели можно было бы интерполировать из соседних, но это привело бы к размытости).

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

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

Другой метод поддержки разных разрешающих способностей и плотности пикселей – рисовать все, используя векторные изображения (такие как PDF или SVG) или код, либо создавать элементы с помощью CSS. В некоторых ситуациях эти методы работают очень хорошо, как правило, для простых объектов. Данные техники также подходят в тех случаях, когда размер, цвет или другие свойства объектов нужно изменять динамически.

Однако чем сложнее объекты, тем больше ресурсов они тратят. А это может привести к возникновению проблем. Повышенная потребность в ресурсах может обернуться большой проблемой для мобильных устройств. К тому же использование одного векторного SVG или PDF-изображения для всех пиксельных плотностей означает, что вы не сможете проконтролировать, как выглядит результат в каждом размере. А это может быть более важным при изменении масштаба для размера, промежуточного заданным рядам 100, 150, 200 %.

Изображение в SVG или PDF с масштабом в 200 % будет выглядеть ярко и четко, но уменьшение его до 140, 150 или 180 %, вероятнее всего, «размоет» резкость.

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

Рисунок 7.5. Решайте, с чего начнете новый документ: с маленькой пиксельной плотности с увеличением масштаба или наоборот

Начало работы с маленького размера гарантирует, что все, что вы делаете, «привязано» к сетке с шагом в 1 пиксель. Если бы мы начали с размера 2×, это означало бы, что нам нужно использовать только четные величины: четное позиционирование, четную высоту, ширину и четные величины стилей слоя. В противном случае, при уменьшении масштаба нечетные величины (1, 3, 5 и т. д.) сократятся на половину пикселей (0,5; 1,5; 2,5), что приведет к размытым очертаниям или ошибке округления.

Рисунок 7.6. Увеличение масштаба до точных кратных величин всегда срабатывает. Уменьшение масштаба может вызвать проблемы

Работа в масштабе 1× означает, что превью 1:1 (где 1 пиксель на дисплее вашего компьютера отображает 1 пиксель в вашем дизайне) на дисплее вашего компьютера будет выглядеть меньше. В некоторых случаях это жизненно важно, потому что дисплей может быть недостаточно большим, чтобы сделать полный «портретный» предпросмотр на дисплее iPhone Retina (960 пикселей высотой плюс пространство для строки меню, окна и нижней панели). С дисплеем Retina на iPad ситуация становится только хуже.

Я знаю не так уж много дисплеев, которые могут вместить 2048 пикселей вертикально. Современный 27-дюймовый дисплей Mac Cinema имеет высоту в 1440 пикселей, поэтому даже если у вас большой монитор, вы не сможете увидеть экран для Retina iPad необрезанным. Retina iPad имеет 3,145,728 пикселей – гораздо скромнее по сравнению с 27-дюймовым дисплеем Cinema в 3,686,400 пикселей. Но как только выйдут в свет компьютеры с высоким PPI[74], предварительный размер уже не будет проблемой.

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

Допустим, что один ваш документ имеет 100 PPI, а другой – 200 PPI. Если вы воспользуетесь функцией Copy Layer Style (Скопировать стиль слоя) на слое в документе с 100 PPI и Paste Layer Style (Вставить стиль слоя) на слое в документе с 200 PPI,стиль слоя изменит масштаб. Тень размером в 1 px (пиксель) превратиться в двухпиксельную.

Вроде бы разумно с точки зрения Photoshop, но, возможно, не то, что вам нужно. Вот почему: если вы внимательно следите за PPI вашего документа, то могли бы установить ваши iPhone-документы на 163 PPI или 326 PPI, а ваши iPad-документы – на 132 PPI и 264 PPI.

Если вы работаете над приложением, которое подходит и для iPhone, и для iPad, велик шанс, что вы будете копировать элементы и стили слоя между вашими макетами под iPhone и iPad. Если разрешение PPI вашего документа устанавливается в соответствии с устройствами, ваши стили слоя каждый раз будут изменять масштаб на 20 %.

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

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

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

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

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

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

В этих сценариях рекомендуется управление цветом, которое предлагает много преимуществ.

При разработке веб-приложений и интерфейсов приложений, ситуация несколько иная. Готовый продукт отобразится на том же устройстве (или том же типе устройства), на котором вы обычно создавали свои произведения: на дисплее компьютера. Однако здесь есть кое-какие сложности. Даже если устройство, на котором вы будете делать веб-приложение или интерфейс приложения будет тем же либо подобным тому, на котором вы собираетесь использовать готовый продукт, у вас будут разные ресурсы для цветопередачи: изображения (как правило, в форматах PNG, GIF и JPEG), разметка стилей (CSS) и код (JavaScript, Java, HTML, Objective-C и т. д.). Подогнать их может оказаться достаточно сложным процессом.

При разработке сайта или приложений мы хотим, чтобы цвета, отображаемые на экране в Photoshop и сохраняемые в файлах, великолепно подходили к тому, что отображается в других приложениях, включая Firefox, Safari и симулятор iOS.

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

Чтобы отключить систему управления цветом RGB в Photoshop, выберите Edit → Color Settings (Редактировать → Настройки цветов) и установите рабочее пространство для RGB на Monitor RGB. Убедитесь, что цветовой профиль каждого документа, с которым вы работаете, настроен на положение Don’t Color Manage This Document (Не управлять цветом этого документа). Это делается с помощью выбора Edit → Assign Profile (Редактировать → Назначить профиль) или с помощью конфигурации дополнительных опций при создании нового документа. Если вы не будете делать этого для каждого документа, с которым работаете, цвета будут неправильно отображаться в самом редакторе Photoshop.

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

Рисунок 7.7. Отключение системы RGB в Photoshop помогает избежать настройки цвета Photoshop на экране или в сохраненных файлах

Рисунок 7.8. С опцией Assign Profile (Назначить профиль) в значении «Не менять» вы изменяете то, как ваш документ будет отображаться на экране, не затрагивая цветовые данные

Рисунок 7.9. При сохранении файлов через опцию Save For Web (Сохранить для веба) в Photoshop, убедитесь, что Convert to sRGB (Преобразовать в sRGB) отключена, также и когда сохраняете в формат JPEG. Иначе вы измените цвет и вызовете несовпадение величин

А вот опция Convert to Profile (Преобразовать профиль) – это нечто иное. С ее помощью можно не только назначить цветовой профиль документа, но и попытаться сохранить вид вашего изображение таким же и на экране. Это достигается путем обработки цветовых данных в каждом файле для каждого пикселя. Преобразование в новый профиль, скорее всего, будет поддерживать способ, каким документ появится на экране, но данные, хранящиеся, в файле будут изменены навсегда. Поэтому используйте эту опцию с осторожностью.

Если вы копируете слой из одного Photoshop документа в другой, проверьте, чтобы для обоих был назначен один цветовой профиль. Если этого нет, то информация о цвете может быть разрушена, так как она перемещается между документами. Вам также нужно убедиться в том, что опция View → Proof Colors (Вид →Цвета пробного отпечатка) отключена. Если нет, то опция Proof Colors изменит способ отображения цветов в вашем документе. А это значит, что они не подойдут другим приложениям.

И, наконец, при сохранении файлов опцией Save for Web (Сохранить для веба), посмотрите, отключена ли Convert to sRGB (Преобразовать в sRGB). Если она активирована, то изображение преобразуется из текущего цветового профиля в цветовой профиль sRGB, таким образом, изменяя цветовые значения, внося деструктивные изменения в файл и вызывая несоответствия с закодированными цветами.

Если вы сохраняете файл в формате JPEG, то также отключите опцию Embed Color Profile (Вставить цветовой профиль) (в некоторых случаях для фотографий вы, возможно, захотите ее оставить и отключить для элементов интерфейса и пиктограмм).

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

Рисунок 7.10. При создании интерфейсов всегда устанавливайте цветовой профиль документаIllustrator в положение Don’t Color Manage this Document (Не управлять цветом этого документа) через Edit → Assign Profile (Редактировать →Назначить профиль)

Рисунок 7.11. Установите положение Don’t Color Manage This Document для каждого Illustrator документа, с которым вы работаете. Также отключите View →Proof Colors

Рисунок 7.12. Сохраняя файлы с опцией Save For Web And Devices (Сохранить для веба и устройств) в Illustrator, проверьте, чтобы опция Convert to sRGB (Преобразовать в sRGB) была отключена

Система управления цветом в Illustrator очень схожа с Photoshop, в случае, если настройки производятся для дизайна под веб или экранные приложения. Для отключения системы управления цветом RGB в редакторе Illustrator перейдите к опции Edit → Color Settings (Редактировать → Настройки цвета) и установите рабочее пространство для RGB на Monitor RGB. Проверьте, чтобы в каждом документе, с которым вы работаете, цвет профиля был установлен в положение Don’t Color Manage This Document (Не управлять цветом этого документа). Для этого выберите Edit → Assign Profile (Редактировать→Назначить профиль). Это должно быть сделано для каждого документа, с которым вы работаете.

Вам также нужно отключить View → Proof Colors (Просмотр→Цвета пробного отпечатка). Если не сделаете этого, Proof Colors изменит способ отображения цветов в вашем документе. А это значит, что они не подойдут другим приложениям. При сохранении файлов опцией Save for Web (Сохранить для веба), посмотрите, отключена ли опцияConvert to sRGB (Преобразовать в sRGB).

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

Рисунок 7.13. Пиктограмма выше – один векторный слой, созданный из нескольких контуров

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

Рисунок 7.14. Фигуры Photoshop «Прямоугольник» и «Закругленный прямоугольник» допускают четкие края на всех сторонах. Чекбокс Snap to Pixels можно найти в окне опций, как правило, вверху экрана

Фигуры «Прямоугольник» и «Закругленный прямоугольник» имеют хорошо скрытую опцию, которая позволяет им прикрепляться к пиксельной сетке, обеспечивая четкие края всем сторонам. Кнопку-флажок Snap to Pixels (Попадать в пиксели) можно найти в панели опций (Option bar), обычно вверху экрана.

К сожалению, у фигуры «Эллипс» нет опции Snap to Pixel (Попадать в пиксели). Если вам нужно нарисовать пиксельный круг, вам поможет в этом «Закругленный прямоугольник с большим радиусом угла».

Вращающиеся слои в Photoshop при 90 или 270º с выбором опций Free Transform Path, Rotate 90º CW или Rotate 90º CCW в меню редактирования могут вызвать проблемы с векторными и растровыми слоями. Качество готового продукта определяется размером иллюстрации. Если слой имеет четные ширину и высоту, все хорошо.

Рисунок 7.15. Обход ошибки вращения Photoshop с помощью вращения Bjango. smashed.by/rotation

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

При перемещении якорных точек векторных контуров Photoshop может продемонстрировать весьма странное поведение, в зависимости от того, насколько увеличен масштаб. При 100 % перемещение стрелкой подвинет вашу векторную точку точно на 1 пиксель. При 200 % перемещение продвинет точку на половину пикселя. При 300 % – на одну треть пикселя. Если вы хотите иметь прекрасные пиксельные векторные фигуры, возможно, вы предпочтете перемещать с шагом в 1 пиксель, даже если вы редактируете при увеличенном масштабе.

Рисунок 7.16. Изменение точки вращения на верхнюю левую до вращения обеспечивает поддержку качества

Мы можем воспользоваться сдвигом в Photoshop даже при 100 %. Откройте ваш документ, выберите Window → Arrange → New Window для создания второго окна документа. Потом вы сможете изменить размер нового окна и переместить его куда-нибудь.

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

Если вам нужно переместить точку, просто нажмите команду Command + `, чтобы включить окно, в котором выставлен масштаб 100 %, переместите элемент с помощью кнопок клавиатуры, потом нажмите Команду Command + `, чтобы переключить обратно. Так как другое окно показывает изображение в масштабе 100 %, перемещение сместит выбранные векторные точки точно на 1 пиксель. Немного неудобно, но гораздо быстрее, чем уменьшать масштаб до 100 %, а потом наоборот, чтобы отредактировать тонкие детали.

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

Заливка и тени добавляют дизайну тело и форму, при этом элементы выглядят натурально, как будто в трехмерном измерении.

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

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

Как в Photoshop, так и в Illustrator, заливка часто завершается градиентами. В Photoshop это лучше всего достигается при применении опций Gradient Fill Layers (Слой заливки градиентом) или Gradient Layer Styles (Градиентные стили слоя), потому что они могут масштабироваться безгранично. В Illustrator заливка градиентом может применяться к любому контуру.

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

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

Рисунок 7.17. Выпуклые фигуры выступают наружу, выражены линейными градиентами от светлого к темному. Выпуклые фигуры выглядят приподнятыми, отлично подходят для кнопок

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

Рисунок 7.19. Вогнутые фигуры могут быть нарисованы как линейные градиенты от темного к светлому. Поперечное сечение (слева). Элементы с градиентной заливкой (справа)

Рисунок 7.20. Линии сверху и снизу выглядят как высеченные каналы. Углубленные линии часто используются как перегородки в пользовательских интерфейсах

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

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

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

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

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

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

Комбинирование слоя заливки градиентом (Gradient Fill Layer) с градиентным стилем слоев (Gradient Layer Style) позволяет вам наложить два различных градиента, создавая более сложные и динамичные результаты. Чтобы соединить градиенты, вам нужно установить режим смешения для градиентов стилей слоя (Gradient Layer Style). Это позволит слою градиентной заливки (Gradient Fill Layer) проявиться через градиент стилей слоя (Gradient Layer Style). В примере, данном ниже, я использовал режим смешения Screen (хорошо для осветления) либо Multiply (хорошо для затемнения).

Рисунок 7.23. Центральная точка углового градиента может перетаскиваться курсором по холсту при открытом градиентном окне

Рисунок 7.24. Для комбинирования градиентов вам нужно установить режим смешивания для стиля градиентного слоя (Gradient Layer Style), т. е. Screen (хорошо для осветления) или Multiply (хорошо для затемнения)

Рисунок 7.25. Неразмытый градиент (слева) в сравнении с размытым (справа). Градиент справа выглядит более гладким (ровным)

Добавление размытия в градиент дает более ровные результаты, потому что дает изысканно-узорчатый эффект или белый шум. Неразмытые градиенты часто содержат визуальную сегментацию (полосатость). Размытие даже больше важно, если ваш рисунок будет просматриваться на дешевых нематических жидкокристаллических экранах (TN LCD) c шестью битами на канал и некоторых других видах дисплеев, где присутствуют проблемы с постеризацией (приданием «плакатного стиля»). Photoshop может размывать слои градиентной заливки, а также градиенты, нарисованные с помощью градиентного инструмента, поэтому советую вам включать эту опцию. Градиенты, нарисованные в Illustrator, не могут размываться, так же как и векторные смарт-объекты (Smart Objects), которые вставляются в Photoshop из Illustrator.

Если вы используете прозрачность как часть градиента, он тоже не будет размываться, что иногда приводит к визуальной сегментации (полосатости). Для определенных случаев есть решение: если вы используете градиент с прозрачностью для того, чтобы осветлить область белым цветом, то использование неразмытого градиента с режимом смешивания слоев на экране (Screen layer blending mode) позволит вам размыть его. Та же техника применяется для затемнения, с режимом смешивания Multiply. Размытие цветов – это ювелирная работа. И подчас оно едва уловимо. В примере слева мы повысили контраст для того, чтобы выделить размытый паттерн. Градиент справа выглядит более ровным, потому что он размыт.

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

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

Однако здесь есть небольшая сложность. Текстуры, как правило, основаны на растровом изображении, поэтому они выглядят как фотография. Как мы уже говорили, растровые изображения или растровые слои масштабируются неудачно, и их нужно избегать, где только возможно. Photoshop предлагает три способа добавления текстуры, которая также будет без разрушений изменять масштаб ваших документов: Pattern Fill Layers (Заливка слоев паттернами), Pattern Layer Styles (Стили заливки паттернами) и Smart Objects (смарт-объекты).

Чтобы создать паттерны в Photoshop мы можем использовать опцию выделения с помощью рамки (Marquee Selection tool) для выбора прямоугольной площади, а затем выбрать опции Edit → Define Pattern (Редактировать → Задать паттерн). После создания паттерн готов к использованию как через слой заполнения паттерном (Pattern Fill Layer), так и через паттерный стиль слоя (Pattern Layer Style).

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

Если хотите проверить точно, как выглядят паттерны в определенных масштабах, то вам придется создавать версии для каждого нужного размера. Например, вы могли бы создать два шаблона для iOS текстуры: один для масштабирования в Retina-устройствах, а другой – для масштабирования в не-Retina-устройствах. Потом при экспорте всех финальных исходников изображения вы бы включили паттерны, используемые в ваших Pattern Fill Layers и Pattern Layer Styles.

Слои заливки паттерном (Pattern Fill Layers) в точности соответствуют своему названию: это слои, заполняемые узорами. Они могут также факультативно содержать векторную маску, поэтому, даже если растровое изображение внутри слоя с паттерном смягчается при масштабировании, границы будут оставаться резкими. Двойной щелчок на миниатюру Pattern Fill Layer на панели слоев открывает опции, позволяющие вам установить масштаб паттерна независимо от масштаба документа.

Стили заливки паттерном (Pattern Layer Styles) подобны заливкам паттерном (Pattern Fills), но применяются как стиль слоя. Это значит, что они не могут использоваться вместе с опциями Solid Color Fill Layers (Заливка слоев однотонным цветом), Gradient Fill Layers (Слой заливки градиентом) и даже с другими слоями Pattern Fill Layers (Заливка паттерном).

В Photoshop смарт-объекты (Smart Objects) – это документы, расположенные внутри слоя, что дает идеальную возможность вставлять текстуру высокого разрешения в документ с низким разрешением. Смарт-объекты формируются, когда формируется их исходный файл. Смарт-объекты, созданные внутри Photoshop, формируются в их исходном размере, затем их масштаб увеличивается или уменьшается с использованием растрового масштабирования.

Лучше всего использовать смарт-объекты в виде прямоугольной области с векторной маской, применяемой для фигуры. Это означает, что сама текстура будет масштабироваться в растровом изображении, а фигура будет перерисована по размерам как векторный объект, создавая четкие границы.

Чтобы создать смарт-объект в Photoshop, щелкните правой кнопкой мыши или кликните левой клавишей с зажатой клавишей Ctrl в слое или группе, затем выберите опцию Convert to Smart Object (Преобразовать в смарт-объект).

Смарт-объекты, созданные вставкой или импортированием файла из редактора Illustrator, по своей природе векторы, поэтому они могут масштабироваться в любой размер и, если нужно, формироваться заново. Смарт-объекты из Illustrator могут иметь множество заливок цвета, обводок и свойств, недоступных векторным слоям в Photoshop. Однако будьте осторожны: смарт-объекты из Illustrator не рисуются размытыми градиентами, поэтому у них могут быть проблемы со сглаживанием.

Чтобы создать смарт-объект из файла Illustrator, выберите File → Place from Photoshop (Файл → Вставить из Photoshop). Также возможно копирование объектов в Illustrator с последующей вставкой в Photoshop.

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

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

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

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

Кроме того, возможности кода – это обычно только часть того, что возможно в Photoshop. Заливка градиентом или сложные стили заливки текста в Photoshop может оказаться непростой, невозможной и нежелательной задачей в приложении или сайте.

Если вы разрабатываете дизайн для iOS, то значение 72 PPI в документе Photoshop задаст размер шрифта близкий к размеру в среде разработки Xcode: текст размером в 10 пунктов в документе Photoshop с масштабом 1х (320 на 480 пикселей для iPhone) будет эквивалентен тексту размером 10 пунктов в iOS. Но помните, что во внешнем виде текста будут некоторые различия в результате рендеринга между Photoshop и iOS.

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

Информация о PPI почти всегда игнорируется, когда изображения используются в Сети или как элементы интерфейса пользователя вприложениях iOS, Android, Windows Metro и Mac.

Тем не менее пиксельные размеры ваших изображений все-таки имеют значение, так что делайте их правильно. Для iOS проверьте, что ваши 2× изображения в точности удваивают размеры ваших 1× изображений и что элементы внутри изображений находятся в одинаковых положениях; ваши изображения Retina должны быть идентичны их меньшим аналогам, но и быть более детальными.

Помните, что изображение в формате PNG сохраняет свое пиксельное разрешение в пикселях на метр (PPM). Это может вызывать ошибки округления, когда величины преобразуются между PPI и PPM. Если вы когда-нибудь видели, как при сохранении изображения в формате PNG его разрешение изменялось с 300 до 299,999 PPI, то вы меня понимаете.

Обработка ваших изображений инструментами сжатия PNG, такими как OptiPNG, PNGcrush, AdvPNG или PNGOUT, может показаться классной идеей! Инструмент работает вовсю, «обрезая» килобайты и байты в каждом файле в надежде улучшить скорость скачивания приложения и ускорить запуск.

Но для кардинального увеличения производительности приложений iOS встроенная среда разработки Xcode перекодирует/пересжимает файлы PNG. Она предварительно умножает разряды альфа-канала в обратном порядке, и байты в красном, зеленом и синем каналах меняют последовательность на синий, зеленый и красный. Затем Xcode перекодирует изображения, используя утилиту PNGCrush. Результат оптимизируется для iOS, но, как побочный эффект, любое предшествующее сжатие остается необратимым из-за того, что изображения перестраиваются.

Определенно, есть причины для оптимизации ваших изображений для веба, есть хорошие инструменты, но если вы создаете приложения iOS в программной среде Cocoa и используете встроенное в программу Xcode сжатие PNG, то не получаете особых преимуществ от предварительного сжатия файлов.

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

Проверка устройств – дело важное, потому что типы экранов, теплота тонов, и даже субпиксельные паттерны значительно различаются. Поэтому вы, возможно, захотите «причесать» дизайн после того как увидите все на своих местах. Некоторые типы дисплеев, например AMOLED, могут выглядеть гораздо насыщеннее и с более высоким контрастом, чем обычные ЖК экраны компьютеров. Я уже не говорю о том, каким захватывающим зрелищем является просмотр вашего дизайна на устройствах.

Есть много способов посмотреть ваш готовый макет на мобильных устройствах. Сброс изображений себе на почту или использование таких сервисов, как Dropbox, срабатывают отлично, так же как и более нестандартные решения, такие как LiveView и Skala Preview. По возможности, проверяйте методом, который поддерживает качество изображения: 32-битовые PNG изображения прекрасны, но сжатие с потерями, например в формате JPEG могло бы показать все артефакты.

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

Сохранение изображений во многих масштабах, которые требуют iOS, Android, Windows Metro и другие платформы, еще усложняет задачу.

Но есть способы упростить или автоматизировать экспорт.

Разрезать ваш дизайн с помощью опции Copy Merged (скопировать объединенные данные) довольно легко: сделайте соответствующие слои видимыми, выделите элемент с помощью опции Marquee selection, выберите Edit → Copy Merged (Редактировать → Скопировать объединенные данные), потом File → New (Файл → Новый), нажмите Enter и затем Paste (Вставить). В результате получится новый документ с вашим изолированным элементом, установленном на минимально возможный размер. С этого момента все, что нужно, это сохранить изображение, используя команды Save As (Сохранить как) или Save For Web And Devices (Сохранить для сети и устройств).

Рисунок 7.26. Разрезать ваш дизайн с помощью Copy Merged достаточно легко: сделайте соответствующие слои видимыми, выделите ваш элемент с помощью опции Marquee selection, выберите Edit → Copy Merged, затем File → New, нажмите Enter и потом Paste

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

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

Вы могли бы создать экшен[75] (операцию), который последовательно запускает опции Copy Merged, New, Paste. Это хоть немного сэкономило бы вам время и улучшило технологический процесс[76].

Если бы вам выпало счастье экспортировать множество одинаковых изображений (как правило, с идентичными размерами), вы могли бы использовать опцию Export Layers (экспортирование слоев в Photoshop) в Files script (Сценарий файла).

При выборе команды File → Scripts → Export Layers to Files (Файл→ Сценарии → Экспортировать слои в файлы), каждый слой вашего документа будет сохраняться как отдельный файл, с названием, которое соответствует названию слоя. Это означает, что, скорее всего, вы должны подготовить свой документ, объединив с растровыми слоями все элементы, которые хотите экспортировать. Процесс трудоемкий, но его можно ускорить, применив опцию Copy Merged. Также это может сократить итоговый файл, если вы хотите полностью удалить прозрачную область. Экспортировать слои в файлы удобно, если желаемый результат соответствует вариантам его использования.

Photoshop-инструмент Slice tool (Нарезка ломтиками) позволяет вам определить прямоугольные участки для экспортирования в виде отдельных изображений с некоторыми ограничениями: на один документ может приходиться только один комплект ломтиков, и ломтики не должны перекрываться (если так будет, то сформируются прямоугольные ломтики меньшего размера). В 1990-е годы опция Slice tool была хорошим способом создания табличных веб-макетов, заполненных изображениями. В наши дни нам нужен более тщательный контроль над тем, как нарезаются изображения, особенно если мы хотим иметь эффективный и динамичный дизайн с прозрачными изображениями. Так или и иначе инструментом Slice tool можно отлично пользоваться.

Рисунок 7.27. С выбором команды File → Scripts → Export Layers to Files каждый слой вашего документа будет сохраняться, как отдельный файл, с названием, соответствующим названию слоя

Спрайты обычно используются в CSS и играх на OpenGL, где их использование может давать значительные преимущества в производительности. Спрайт – это большое изображение, которое состоит из более мелких графических элементов. При использовании спрайтов только одно большое изображение загружается в браузер, уменьшая количество HTTP-запросов. Подобное улучшение производительности происходит с OpenGL играми, где один файл, сохраненный в памяти GPU, может использоваться со ссылкой на множество меньших изображений в нем.

Рисунок 7.28. Спрайты требуют времени на создание, но они помогают автоматизировать экспортирование изображений

Рисунок 7.29. После создания спрайта с ломтиками все устанавливается корректно. Вы сможете экспортировать все изображения сразу же, используя команду Save for Web & Devices

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

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

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

Так как нас интересуют только ломтики, которые создает пользователь, возможно, вам захочется «щелкнуть» на команду Hide Auto Slices (Скрыть автоломтики) в окне опций при использовании инструмента Slice Select tool и отключить Show Slice Numbers (Показать количество ломтиков) – под Guides, Grid & Slices в настройке. Таким образом, будет удален ненужный беспорядок из Photoshop ломтиков пользовательского интерфейса. После создания спрайта с ломтиками все устанавливается корректно, вы можете экспортировать изображения сразу же, используя команду Save for Web & Devices. А чтобы убедиться, что вы все сделали как следует, вы можете увеличить масштаб до 200 %, сохранить все ваши изображения для дисплеев Retina, а потом добавить @2x к названиям файлов пакетным переименованием (или уменьшить масштаб, если вы сначала все создаете на размерах дисплеев Retina).

Если ваш элемент пользовательского интерфейса однослойный, а вы хотите, чтобы экспортируемое изображение было маленьким насколько это возможно, то рассмотрите использование опции Layer Based Slice. Для того, чтобы создать ломтик для выбранного слоя, используйте опцию New Layer Based Slice (Новый ломтик на основке слоя) из Layers menu (Меню слоев). Ломтики на основе слоя (Layer Based Slices) передвигаются, увеличиваются и уменьшаются вместе со слоем, к которому привязаны. Они также учитывают эффекты слоя: контуры и тени включены, и увеличивают размер ломтика на основе слоя. Меньше контроля, больше автоматизации!

В течение нескольких лет я пользовался Copy Merged в качестве основного метода экспортирования и использовал Export Layers to Files, когда это имело смысл. Это был скудный выбор. Спрайты имеют так много плюсов, особенно для средних и больших проектов, что время на первоначальное их создание проходит очень быстро. Это еще более оправдано при экспорте множества комплектов изображений с разными пиксельными плотностями. Каждый комплект может экспортироваться несколькими кликами, а до проблем с названием или размером далеко благодаря автоматизированному процессу.

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

Рисунок 7.30. Отключение зеленого канала помогает увидеть разницу между макетом и настоящим приложением

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

Есть вероятность того, что даже если вы провели мало времени за дизайном, то слышали о персонажах. Может быть, вы даже создали несколько. Мы спрашиваем себя: «Кто же они?» с момента, когда Алан Купер представил персонажей в интерактивном дизайне в 1995 году, и с тех пор они стали главным продуктом дизайна, ориентированном на пользователя. Если персонажи для вас неосвоенная территория, вы можете найти краткое введение по теме в «The Project Guide to UX Design»[78] Руса Унгера и Каролин Чендлер. Если вы желаете покопаться глубже в исследовании пользователей, раздобудьте специализированную книгу Алана Купера «The Inmates Are Running the Asylum»[79].

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

Рисунок 8.1. Персонаж описывает портрет основного пользователя в нашей целевой аудитории и одушевляет наши дизайнерские решения. Этот пример создал Тод Заки Ворфел из messagefirst.com

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

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

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

Не так давно те из нас, кто публиковался в Сети, были вынуждены выглядеть более пафосно перед публикой. У вас был сайт во время бума доткомов в конце 1990-х? У меня – да, и, уподобляясь многим, я писал тексты для моих сайтов с королевским «мы», чтобы создать впечатление того, что моя корпорация такая же огромная, как iXL или Razorfish[80] (дети, спросите у родителей!). Выбросите стоковые фотографии фиктивных партнеров и встреч, и вы превратитесь в одиночку, который сидит в своей спальне и выдает себя за «всемирную корпорацию».

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

Рисунок 8.2. И Carbonmade, и Photojojo имеют яркую индивидуальность, которая выделяет их среди конкурентов и привлекает страстных поклонников

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

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

Некоторые компании поняли это и сейчас налаживают эмоциональные связи со своими клиентами с учетом их индивидуальности. Мы сейчас созрели до того, чтобы ожидать этого от маленьких «стартапов», таких как Carbonmade[81] – это забавное веб-приложение, которое помогает дизайнерам создавать портфолио, и Photojojo[82], площадки для фотографов. Эти компании свободны от корпоративных ограничений и переполнены креативностью. Их дизайн и маркетинг блещет юмором, что выделяет их среди конкурентов. Просто индивидуальность – это мощное оружие при создании дизайна, которое работает даже с гигантскими конгломератами.

Компания General Electric, компания из списка Fortune-100 со штатом в 287 000 сотрудников (хм, людей в 36 раз больше, чем в городе, где я вырос), выглядит гигантом по сравнению с почти любой компанией на планете. Многие корпоративные монстры любят размещать на своем сайте стандартные тексты, стоковые фотографии и обещания. Но GE пробует кое-что другое. Она рассказывает истории устами своих сотрудников о том, как изменяет мир.

В видео на домашней странице GE[83] рабочие из Дарема (штат Северная Каролина, США) делятся с нами вкратце рассказами о своей работе, о том, как они создают мощные реактивные двигатели, которые поднимают коммерческие самолеты на высоту 1000 метров над землей. Это видео не о том, насколько сложны технологии, заложенные в двигатели, а собрание личных историй Сеза, Марка, Карима, Тома и их коллег, которые вкладывают душу в свою работу.

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

Рисунок 8.3. Компания GE представляет на своей домашней странице рассказы тех людей, которые делают ее продукцию. Индивидуальность компании освещена личностями, которые страстно привержены своему делу

Как видно из видеоролика, члены команды идут по взлетной полосе и видят, как взлетает авиалайнер-гигант, чье сердце – это двигатели, собранные ими.

Все поглощены тем зрелищем, как лайнер набирает высоту.

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

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

Стивен Пинкер, профессор кафедры психологии Гарвардского университета в своем бестселлере «How the Mind Works»[84] («Работа ума») отмечает: «Многие изменения в личности – около пятидесяти процентов – имеют генетические корни». И это так! В момент, когда вы входите в этот мир, половина качеств вашей личности уже предрешены свыше.

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

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

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

Есть четыре основных выгоды от выражения вашей личности через дизайн:

• На переполненном рынке индивидуальность поможет вам отделиться от конкурентов.

• Индивидуальность вызывает у аудитории эмоциональную реакцию, и ваш бренд запоминается надолго.

• Личность привлекает тех, кто понимает вас, и удерживает на расстоянии всех остальных.

• Индивидуальность вызывает у пользователей страсть, и они становятся самым мощным маркетинговым каналом.

Неважно, какой у вас сайт, в Сети найдется десяток, похожих на него. Поставьте себя на место вашей аудитории. Как они отличат ваш сайт от других? В чем разница между ними? Компания по бронированию путешествий Hipmunk[85] тщательно рассматривает эти вопросы прежде, чем окунуться в кишащий конкурентами рынок. Travelocity, Orbitz, Expedia и несколько других компаний одно время крепко держались за рынок онлайн-бронирования путешествий, но Hipmunk удалось выделиться из толпы.

Зайдите на некоторые известные сайты для путешествий, и вы найдете в них общие черты, которые выражают их индивидуальность. Их домашние страницы пестрят объявлениями о последних сделках по путешествиям и гарантиями на возврат денег. Растерянный пользователь отвлекается от своей основной цели, с которой он зашел на сайт, – забронировать рейс. Каждый из этих элементов чего-то требует от пользователей. «Дай мне! Дай мне!» – вопят они.

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

Дизайн большинства сайтов туризма и путешествий, привлекающий внимание «агрессивными нападками», не улучшает такое эмоциональное состояние. А вот спокойный, сосредоточенный образ – лучшее лекарство от стресса. Это в точности то, что предлагает сайт компании Hipmunk. Его домашняя страница прямо сосредоточена на одном: выбор рейса. Забавный бурундучок добавляет необходимой ветреной легкости в противовес стрессовому взаимодействию. Нет никаких предложений о скидках, которые отвлекают или еще больше напрягают пользователя.

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

Рисунок 8.4. Забавный персонаж – бурундучок – и однонаправленность сайта – прекрасное лекарство от вывода из стрессового состояния многих людей, которые пользуются услугами сервиса бронирования поездок

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

Эмоциональные переживания оставляют глубокий отпечаток в нашей памяти. И возникновение эмоций, и их запоминание происходят в лимбической системе – совокупности отделов головного мозга. Есть хорошая причина, по которой лимбическая система объединяет эти важные функции. Мозг объединяет эмоцию и долговременную память потому что, в противном случае, человек был бы обречен на повторение негативных впечатлений и не мог бы осознанно повторять позитивные. Как Джон Медина разъясняет в своей книге «Brain Rules: Principles of Surviving and Thriving at Work, Home and School»[86] («Правила мозга: 12 принципов выживания и процветания на работе, дома и в школе») наш мозг тонко подмечает эмоционально наполненные события:

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

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

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

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

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

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

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

В нашей личной жизни есть несметное количество случайных лиц, которых мы и в глаза не видели. Конечно, тяжело осознавать, что некоторые люди не принимают наш образ на ура. Глупо пытаться подстраиваться под желания всех, с кем нас так или иначе сводит судьба. Самое лучшее, что мы можем сделать, оставаться самими собой и верить, что есть люди на планете, которые принимают нас такими, какие мы есть. (Бог мой! По-моему, мы под шумок внесли лекцию о жизни в книгу о дизайне, вам не кажется?)

Эта лекция имеет отношение к дизайну. Образы помогут вам отфильтровать свою аудиторию на тех, с кем у вас общие ценности, интересы и цели. Эти люди – ваши пользователи. Вот им и надо стараться угодить. А они, в свою очередь, открыто выразят всю свою любовь вашему бренду.

Как ведущему дизайнеру пользовательского опыта в Мейлчимпе, мне это известно из первых рук. Юмор, остроты и веселые времена, что я переживаю каждый день с моими коллегами, отражаются в текстах, иллюстрациях и интерактивном дизайне, которые мы создаем. Приколы Фредди фон Чимпенхаймера IV, нашего талисмана, шимпанзе, который сидит вверху каждой страницы приложения, собраны людьми нашей компании. Так выражается наше чувство юмора. Когда вы взаимодействуете с сайтом MailChimp, вы взаимодействуете с теми, кто его создавал.

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

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

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

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

Образы в дизайне помогают распространить слух о нас. Не надо никакой дополнительной рекламы. Wufoo[87], разработчики веб-приложения, которое упрощает создание веб-форм и управление собранными данными, полностью ликвидировали свой маркетинговый бюджет, когда увидели, что пользователи рекламируют приложение за них.

Рисунок 8.5. Уникальный метод разработки дизайна приложения Wufoo, сосредоточенный на бизнесе, вызывает восхищение и восторг пользователей, которые горят желанием поделиться с миром их положительными впечатлениями

Записи в Twitter, посты в блогах и простая молва привлекли новых пользователей более эффективно, чем баннеры. Неизбитый дизайн сайта, остроумный текст и озорник Динозаврик резко выделяют Wufoo в среде конкурентов, которые с большой неохотой используют образы. Пользуясь сайтом Wufoo, мы легко можем увидеть образы тех людей, кто его создавал[88]. Владение продуктом, любимым пользователями и который постоянно растет за счет сарафанного радио, сделало Wufoo привлекательным и ценным приобретением для компании SurveyMonkey[89], что купила его в 2011 году приблизительно за 35 миллионов долларов.

Уважаемые дизайнеры пользовательского опыта, такие как Стивен Андерсон и Энди Бад, размышляют и говорят о связи между образами, эмоциями и дизайном вот уже несколько лет. Тема нашла поддержку в дизайнерской среде. Но мы не единственные, кто осознает силу образов на переполненном рынке. Люди, которые создают стартапы, тоже понимают это.

В своем блоге Фред Уилсон, венчурный капиталист и директор компании Union Square Ventures, выступает за ясность речи и образов в дизайне продукта, и высказывает мысль, что это является «решающим в создании успешного продукта»[90].

Дейв Мак-Клер, «инвестор-ангел» и основатель бизнес-инкубатора из 500 мелких компаний, придерживается того же мнения. Он рассматривает образы и эмоции как важныe факторы успеха продукции. В своей речи на конференции Warm Gun conference в 2011 году Мак-Клер обратился к дизайнерам и предпринимателям: «Будьте собой, суперсамими собой. В чем вы можете быть искренними и где вам уютно? Ищите свою сущность и расширяйте ее. Найдите чувство или эмоции, которые вы можете поддерживать»[91].

Бизнес-СМИ также раскрывают роль образов в дизайне. Спонсор журнала Forbes Энтони Винг Коснер подтверждает, что образы могут сделать сайт более запоминающимся:

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

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

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

1. Название бренда

Название вашей компании или продукта.

2. Обзор

Краткий обзор образа вашего бренда. В чем его уникальность?

3. Образ индивидуальности/личности

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

4. Качества бренда

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

5. Схема образа

Мы можем изобразить образ графически. Ось Х изменяется от враждебной к дружелюбной, а ось У – от покорной до господствующей[94].

6. Речь

Если бы ваш бренд мог говорить, как бы он это делал? Что бы он сказал? Разговаривал бы он компанейским простым языком, или утонченным?

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

7. Примеры текста

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

8. Визуальный словарь

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

9. Методы привлечения

Опишите методы, которыми вы могли бы эмоционально привлечь ваших пользователей, чтобы создать незабываемые впечатления. Пачка карточек с ментальными заметками Стивена Андерсена очень удобное собрание таких методов[95].

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

Чтобы начать работать над вашим дизайн-персонажем, сначала скачайте образцы и шаблоны[96]. Если вы работаете в команде, соберитесь все вместе с легкой закуской и маркерной доской, чтобы проработать первоначальные идеи по поводу образа. Будет весело, и никому не повредит холодильник со взрослыми напитками.

Начните дискуссию с вопроса: «Какие семь слов могут описать нас лучше всего?» Будьте честными. Вы можете услышать такие характеристики, от которых не загордитесь. А теперь уточните: «Какие семь слов могут описать того, кем мы надеемся стать после редизайна?» Переделка сайтов по своей сути желательна и полезна, так как основывается на наших стремлениях.

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

В окончательном списке, «нацарапанном» на доске, отразите границы каждой характеристики. Каким бы вы не хотели видеть свой образ? Например, если в списке стоит характеристика «веселый», это может означать много чего. Веселый, как Элмо[97], или веселый от того, что с ветерком едешь за рулем Ferrari California вдоль Блуриджской парковой автострады? Рамки привнесут ясность в досье дизайн-персонажа и помогут вам увидеть во время проекта, когда пересекается граница.

Чтобы лучше понимать, как работают характеристики и рамки, посмотрим, как мы определили их для образа MailChimp:

1. Веселый, но не по-детски.

2. Забавный, но не тупой.

3. Функциональный, но не сложный.

4. Неформальный, но не разгильдяйский.

5. Простой, но не простецкий.

6. Надежный, но не нудный.

7. Неформальный, но не чуждый.

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

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

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

При создании образа для вашего сайта помните одно важное правило.

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

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

Когда мы делали нашего дизайн-персонажа в MailChimp, мы просто документировали коллективный образ людей нашей команды. В действительности, мы обнаружили, что задача не была сложной, потому что наняли людей с одинаковыми взглядами, одинаковым чувством юмора и другими качествами. Хотя наша приоритетная цель была найти людей, которые сработаются, процесс также оказался полезным для определения образа бренда. Представляем вам дизайн-персонаж[98].

Название бренда

MailChimp.

Обзор

Фредди фон Чимпенхаймер IV – лицо MailChimp и воплощение образа бренда. Крепкая фигура Фредди символизирует мощь приложения, а его поза демонстрирует, что он находится в движении. У Фредди всегда милая улыбка, которая привлекает пользователей, и они чувствуют себя уютно на сайте.

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

MailChimp часто подбрасывает пользователям забавные «пасхальные яйца»[99] или ссылки на смешные видеоролики на You-Tube. Веселье и забавы живут в каждом уголке сайта, но никогда не станут мешать вашей работе.

Характеристики бренда

Веселый, но не по-детски. Забавный, но не тупой. Функциональный, но не сложный. Неформальный, но не разгильдяйский. Простой, но не простецкий. Надежный, но не нудный. Неформальный, но не чуждый.

Голос

Голос MailChimp знакомый, дружелюбный, а главное – человеческий. Понятно, что за брендом на самом деле стоят образы людей. MailChimp отпускает шуточки (вы сможете рассказать их маме), рассказывает истории и говорит в непринужденной манере, в какой вы могли бы разговаривать со старым приятелем. MailChimp употребляет конструкцию don’t вместо do not, потому что так говорят нормальные люди. MailChimp вставляет неформальные междометия типа «хм-м-м», когда думает, и «Блин! Это ужасно!» – чтобы выразить сочувствие.

Примеры текста

• Сообщение об успехе: «Дай пять! Твой список импортирован».

• Сообщение об ошибке: «Упс! Кажется, ты забыл ввести адрес электронки».

• Критический отказ: «Один из наших серверов временно не работает. Наши инженеры уже работают и скоро все исправят. Спасибо за понимание».

Рисунок 8.6. Досье дизайн-персонажа, созданное для образа сайта MailChimp

Визуальный словарь

• Цвет. Яркая, но все же слегка ненасыщенная палитра MailChimp передает радость – цвета чистые, но не как в детских телепередачах. Следуя характеристикам бренда, цвета воплощают юмор, и при этом они действенные и изысканные.

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

• Основной стиль. Элементы интерфейса – простые и ровные, делают восприятие всего доступным и не отпугивающим. Мягкая, утонченная текстура может проявиться в капельках, согревая пространство. Фредди используется изредка, и то, только чтобы впустить струйку юмора. Он не влияет ни на обратную связь или статистику, ни помогает выполнять задачи.

Методы привлечения

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

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

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

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

Рисунок 8.7. Талисман Фредди фон Чимпенхаймер IV, талисман (лицо) MailChimp

Рисунок 8.8. Схема образа MailChimp

Держа образ в голове, мы начали осознавать его присутствие во всем, что создаем, особенно, пишем. Посты в блог, тексты о продукте, статьи базы знаний руководство по поддержке – везде есть наш образ. Хотя мы не всегда делали все классно. Мы допускали и неуместный юмор. Когда пользователь нервничает, потому что ему, кровь из носа, надо выполнить задание в срок, а он никак не может сосредоточиться, шутки и неформальный тон не к месту.

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

Вы когда-нибудь писали руководство по стилю, которое закладывает стандарты дизайна или текстов для компании? Руководства по стилю устанавливают мириады сценариев, в которых дизайн или текст могут пострадать, и они задают рамки, в которых можно долго топтаться на месте.

Многие переделки начинаются с руководств, кишащих благими намерениями, но в большинстве своем проекты забрасываются, потому что постоянное обращение к руководству непрактично. У людей создается впечатление, что у них за плечами стоит «полиция нравов». Кейт Кифер Ли написала для нас содержательное руководство по стилю, которое помогает опытным и новоиспеченным авторам. У нее были некоторые оговорки по тому, как коллеги будут воспринимать его. Будут люди использовать его реально, или для них это будет обузой? В плане грамматики и пунктуации сложностей не возникло, но вот как было донести до коллег взаимосвязь между голосом и тоном?

Когда Кейт объединила посты в блог, базу знаний, средства обучения и руководства, чтобы оценить голос компании, она отметила участок, где голос MailChimp был чистым, без интонации.

Стали бы вы шутить, чтобы утешить вдову на похоронах? Или использовать неформальную речь на встрече с королевой Англии? Думаю, что нет! Естественно, вы бы захотели настроить свой тон по ситуации.

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

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

Этот метод определения образа и стиля написания был воспринят хорошо. Просто понимать, весело использовать. Нет кучи правил и ограничений. Никто не хочет быть под прицелом «полиции нравов». Это руководство дает людям свободу писать, используя голос MailChimp, когда тон правильно подобран.

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

Рисунок 8.9. Руководство «Голос и тон» помогает всем, кто пишет для сайта MailChimp, поддерживать голос и индивидуальность бренда при адаптации тона под эмоциональный настрой читателя

Примеры текста в руководстве «Голос и тон» не только определяют чувства читателей в конкретных ситуациях, но и сопровождаются соответствующими цветами на фоне странице. Красный фон символизирует злость и расстройство, в то время как зеленый – восторг и радость. Как любое руководство по стилю, «Голос и тон» помогает авторам устанавливать и поддерживать постоянство, часто проповедуемое качество бренда, которое взращивает доверие пользователей и укрепляет взаимоотношения с ними. Руководство так же обращает внимание на важность адаптации. Вместо того чтобы быть категоричным в стиле, оно просто представляет спектр стилей общения, которые авторы смогут применять в различных ситуациях[101].

Вы замечали, как люди волей-неволей бросаются термином «родной», не до конца понимая, что это на самом деле значит? Давайте исправим ситуацию. Начнем с того, что выясним, чем «родной» не является.

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

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

Фото: Дэвид Джонс / smashed.by/davidjones

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

Каждая из этих технологий основана на абстракциях. Например, Питон написан на Си. Цель каждого абстрактного слоя – каждого более высокого слоя в слоеном торте технологий, которые составляют современную компьютерную экосистему – упростить разработчикам создание приложений. Так что употребление термина «родной» в смысле бинарного программирования сегодня поблекло.

Итак, теперь, когда мы знаем, что такое «неродной», давайте выясним обратное.

Рисунок 9.2. Веб-технологии могут быть «родными» для определенных операционных систем. Здесь вы видите лэптоп Samsung с системой Chrome OS, чьи первостатейные граждане – HTML, CSS и JavaScript и веб-приложения. Фото: промо-изображение Google

Пока разработчики свято верят в то, что будущее Сети – исключительно в разнообразных авторских веб-технологиях, таких как HTML, CSS и JavaScript, которые обеспечат лучший доступ к таким свойствам устройств, как тач, GPS, поддержка акселерометра и камеры, я буду спорить. Очень редко говорят о том, как «родные» приложения догоняют веб-приложения.

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

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

Рисунок 9.9. Граница между потоком использования «родных» веб-приложений или «родных» OS-приложений размытая. Фактически в операционных системах, основанных на веб-технологиях, «родные» веб-приложения – это «родные» OS-приложения

Одно из основных преимуществ опыта взаимодействия, которое Сеть имеет от «родных» приложений, это – легкость, с которой они могут использоваться и быть доступными. Нажмите клавишу Upload (Загрузить) в вашем FTP-клиенте по выбору[110], и разработанное приложение станет доступным каждому, у кого есть ссылка на него, в любом уголке мира[111]. Все просто.

Не нужно скачивать Zip-файл, потом искать приложение, чтобы разархивировать его, потом искать, куда оно скачалось, потом распаковывать архив, устанавливать, запускать. И все это только для того, чтобы узнать, что оно не поддерживается вашей видеокартой. Ик! Вас не удивляет, что такие веб-приложения, как Gmail и Google Docs обрели феноменальный успех, особенно на «родных» платформах с низким уровнем удобства в работе?

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

По своей природе веб-приложения всегда находятся в обновленном состоянии. На самом деле мы совсем не думаем о «версии» веб-приложения, потому что Сеть, по сути, независима от версий.

Вы всегда пользуетесь последней версией Gmail, и вам все равно, что это за версия.

Это не Gmail версии 7; это просто Gmail[112].

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

Это тоже меняется. Все больше и больше «родных» приложений выполняют непрерывное обновление. К примеру, когда вы в последний раз видели, как Google Chrome обновлялся? Да никогда. Он делает это тихо.

Другое огромное преимущество, которым пользователи веб-приложений обычно наслаждаются, это непрерывный доступ к своим данным с любого устройства. Вам никогда не нужно волноваться о синхронизации e-mail с вашего компьютера на мобильный телефон, когда вы пользуетесь сервисом Gmail. Это всегда в нем. Сравните это с ночным кошмаром, который обычно «обрушивается» на синхронизацию на «родных» платформах.

Однако, как ни крути, «родные» приложения снова наверстывают упущенное. Например, с сервисом iCloud от Apple, синхронизация вручную становится вчерашним днем. Ваши данные легко и просто доступны автоматически на ваших устройствах Apple и постоянно находятся в процессе синхронизации, и у вас не должна болеть об этом голова. Хотя сервис iCloud по большому счету клиентское решение Apple, кроссплатформенные технологии типа Dropbox дают похожие преимущества другим платформам.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 9.14. Бинарно-каркасная матрица

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

«Родной» бинарный файл – это пакет приложений, которые могут запускаться напрямую операционной системой данного устройства. Мы, как правило, говорим об этом, когда ссылаемся на «родное» приложение.

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

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

Если все же вы решаете поддерживать одиночную платформу, вам все равно нужно выбрать технологию. Если вы делаете игровое или другое интерактивное приложение, то можете взять кроссплатформенную технологию, такую как Corona от Ansca, Unity или Adobe Flash, которые существенно облегчают разработку подобных приложений.

Если вы создаете не интерактивное приложение, у вас есть выбор между такими кроссплатформенными наборами средств, как Titanium Mobile или Mono. Недостаток здесь в том, что процесс разработки потребует еще одного дополнительного преобразования, и вы мало сможете контролировать оптимизацию вашего приложения, потому что в какой-то степени будете полагаться на «родной» код, написанный специалистами Titanium. Даже если вы погружаетесь в Titanium (или похожий фреймворк типа Mono), помните, что вам все равно нужно изучить «родные» фреймворки (или API) платформы, на которой вы собираетесь работать. Изучать новые фреймворки гораздо сложнее, чем новые языки программирования.

Хотя опытный программист может освоить такой язык программирования, как Objective-C, в считанные дни, у разработчиков уйдут недели (а то и месяцы, даже года) на то, чтобы полностью вникнуть и приноровиться к паттернам, культуре и тонкостям такого фреймворка, как Cocoa Touch.

В конце концов, вы можете использовать «родной» набор средств платформы, которую выберете. Например, вы можете использовать XСode с Objective-C и Cocoa Touch для разработки «родного» iOS-приложения, или Eclipse с Android SDK для создания «родного» Android-приложения, или Visual Studio с C# и фреймворком. NET для разработки Windows Phone-приложения.

Это может включать в себя изучение нового языка программирования (Objective-C для iOS, Java для Android и C# для Windows Phone) или привлечение группы специалистов, которые знают эти языки и имеют опыт работы с «родными» фреймворками. Как мы уже говорили, выбрать новый язык легко, гораздо сложнее изучить новый фреймворк. Не забывайте об этом, когда будете решать, идти ли вам таким путем, если ни вы, ни ваши специалисты не обладают необходимыми навыками.

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

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

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

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

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

Намеренное игнорирование нашего пункта назначения и фокусирование на том, где мы есть и на самом ли деле хотим начать отсюда, требует от нас немалой гибкости. На сегодня одна из больших проблем Cети в том, что технологии влияют на принятие решений больше, чем следует. Возможности устройства становятся поводом для используемых функций. Система управления контентом выбирается еще до того, как мы решаем, что будет делать приложение и для кого оно. «Хотим использовать HTML5», – заявляем мы.

Естественно, что люди сосредотачиваются на технологии. Ведь технология – это захватывающая и такая классная забава. Веб-технологии – это игрушки, инструменты, всякие штуки, который используют «все». Вместо того чтобы дать нашей проблеме подвести нас к выбору правильной технологии для решения, мы смотрим на классные демоверсии и придумываем повод использовать их. Мы забываем о том, что эти демоверсии делают люди, которые…ну, делают демоверсии. Когда вы занимаетесь проектом редизайна, это реальная жизнь. Вам нужно сделать вещь, которая действует. «Круто» – это, конечно, хорошо, но только в том случае, если это работает и решает проблему. Сегодня все внимание слишком часто приковывается к решениям, а не проблемам. Нам надо на время превратиться в пессимистов и сосредоточиться на всех наших проблемах – сосредоточиться на них пристально, позволить им вырасти. Тем, кто имеет дело с веб-технологиями (т. е. вам), ответы придут на ум прямо в душе.

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

Предположим, что мы работаем над сайтом, который обучает разработчиков CSS гибкой модульной верстке (или Flexbox), относительно новому модулю для разметки, которая имеет большие возможности в мультиплатформенном пространстве[120].

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

«Три маленьких прямоугольника» будут состоять из теории и синтаксиса, а также нескольких заданий, каждое из которых строится на основе предыдущего задания. Пользователь сможет написать их код в редакторе на странице, и кнопка «результат» покажет результат кода. Щелчком по клавише «Запустить» запускается введенный код. Каждое задание имеет два вида текстового контента: теорию и задание. Теория объясняет синтаксис и концепцию, а задания являются упражнениями, которые даются студентам для закрепления.

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

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

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

Рисунок 10.2. Такой стиль прототипа обычен. Хотя, скорее всего, он и полезен, он здорово похож на реальный сайт, и только надпись «Прототип» выдает, что это не так. И визуальный дизайн, и контент подвергаются здесь детальной проработке, комбинация, которую возможно лучше обработать через прототип HTML, потому что создание нескольких вариаций для различных размеров экранов на такой ранней стадии проекта в лучшем случае будет нудным. Честно говоря, такая ранняя модель прототипа страницы из Википедии, возможно, служит своей цели. Но минусы для технологического процесса, дружелюбного к будущему проекта, очевидны.

Иллюстрация: Fabrice Florin, Wikimedia Foundation под лицензией CC-BY-SA и GFD / smashed.by/wkpmckp

Я называю эти уменьшенные модели «прототипами со ссылкой на контент». Если клиенту не понравятся ваши прототипы, вы потеряете всего лишь несколько минут работы. Цель такова: показать клиенту не «дизайн», а то, какой контент будет отражен в данном контексте, приблизительно обрисовав расположение и композицию, как предшествие визуальному дизайну. Это создает контраст с тем, как сегодня оформляются многие шаблоны, где графический дизайн уменьшается до размеров детской книжки-раскраски.

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

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

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

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

С этого момента прототипы становятся интереснее. Используя медиазапросы CSS, мы сможем начать работу над грубыми разметками для экранов различных размеров. Благодаря этому два наших прототипа превратятся в бесчисленное количество, потому что их так легко загрузить в браузер любого устройства. Потом мы сможем проанализировать возможности разметки и показать прототипы клиенту[121].

Я часто показываю клиентам скриншоты прототипов в различных размерах (чтобы не создать впечатление того, что процесс разработки будет скорым).

Но для самих себя просмотр прототипов на различных устройствах имеет свои преимущества.

Мы заверстали два прототипа (рис. 10.3 и 10.4.) для нашего сайта «Три маленьких прямоугольника», по одной на каждую главную страницу, пронумеровали согласно пунктам в нашем списке перечня контента. Я также добавил названия позиций, чтобы мы то и дело не заглядывали в список:

Рисунки 10.3 и 10.4

Рисунки 10.5–10.8

Если мы что-то изменяем в перечне, прототип обновляется незначительно. Здесь мы использовали блоки (div) для ускорения процесса, и добавили немного CSS для оформления блоков и разметки.

Рис. 10.3–10.8. показывают наши два, да, только два прототипа на экранах разной ширины. Снаряженные медиазапросами CSS наши прототипы, основанные на HTML, позволяют нам изучить мультиплатформенную верстку на ранней стадии разработки. Мы уже можем начать подумывать о приоритетах и эффекте близости на экранах разных размеров. Представьте, что вы используете графические приложения для визуализации этих изменений в шаблоне, который богат на контент так же, как и модель Википедии (мы видели ее выше). Представьте объем работы над каждым незначительным изменением.

Рисунок 10.9. Простой структурированный контент. Это домашняя страница. «Три маленьких прямоугольника», которую я написал на Markdown. Преобразовать Markdown в HTML просто. Для этой цели я использовал Pandoc. Pandoc – это гибкий, универсальный конвертер: smashed.by/pandoc

В начальной точке создания прототипа, подумайте, как бы мы организовали наш контент, если бы не было никакой разметки, кроме линейной, той, что мы часто встречаем в мобильных версиях сайтов, когда один кусок контента располагается под другим. Эта философия «Сначала мобильные» («Mobile first»), которую популяризировал Люк Вроблевски, основывается на доступности и прогрессивном улучшении[122]. Вы можете сказать, что цель заключается в разработке основного отображения приложения, которое функционирует достаточно хорошо везде, где может быть отрендерен простой HTML.

Рисунки 10.10–10.12. Эти скриншоты показывают наш структурированый в HTML-контент в браузере. Иллюстрации (вверху слева и внизу) показывают стили браузера по умолчанию в Opera Mobile Emulator и Firefox на компьютере соответственно. В варианте справа вверху мы начали работать над типографикой

Задайте себе вопрос о том, какой контент должен идти первым, какой вторым, какой последним и как это может повлиять на порядок нашего исходного кода.

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

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

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

Кстати, все это можно сделать в HTML и CSS. Если вы берете разметку в формате plain-text, такую как Markdown, и потом преобразуете ее в HTML, вы можете создать структурированный дизайн контента так же быстро, как и в текстовом редакторе. Таким способом вы также можете взять базовый HTML и CSS, чтобы использовать для запуска адаптивного (отзывчивого) прототипа.

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

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

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

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

• Некоторые устройства имеют возможности, которые мы бы хотели использовать в наших целях, например камеру или функцию GPS. Многие из нас хотели бы использовать функциональные свойства JavaScript, если они доступны (и часто это так и есть, правда, не всегда, особенно в устройствах низкого уровня). Как насчет визуальных улучшений, таких как встраивание шрифтов и CSS-градиентов? Разработка в актуальных браузерах современных устройств позволяет нам проверить работают ли эти свойства (и работают ли как следует) и как они влияют на качество функционирования. Нам надо подумать о свойствах, которые лучше исключить из определенных устройств и платформ, и поддерживать их на других.

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

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

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

• с поддержкой HTML: необходима для обучающего текстового контента (теория и синтаксис);

• с поддержкой JavaScript: обязательна для интерактивных заданий;

• с большими экранами: не требуются для текстового контента, но удобны для упражнений;

• с кнопочной (неэкранной) клавиатурой: предпочтительна для набора кода;

• с браузером, который должен поддерживать последние спецификации Flexbox (иначе не будут работать упражнения).

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

Значит ли это, что улучшения несерьезны и не важны? Конечно же, нет.

Возьмем, к примеру, простое приложение для списка дел. Цель такова – сделать приложение используемым независимо от платформы; браузер должен только поддерживать HTML, включая основные функции для форм. Спору нет, что приложение списка дел должно позволять пользователю совершать по крайней мере несколько вещей:

• добавлять пункты дел,

• редактировать текущие пункты,

• отмечать пункты как выполненные,

• архивировать и удалять старые пункты.

Раньше мы рассматривали три вещи, которые хотели бы изменить по возможности для определенных классов устройств и/или размеров экранов:

• дизайн и расположение,

• функциональность и свойства,

• контент.

Точки, где эти изменения имеют место, называются точками прерывания. Они очень часто устанавливаются в отношении ширины окна просмотра в пикселях, в таких случаях они обычно вводятся в медиазапросы CSS и/или JavaScript. Например, вы могли бы сказать, что когда окно просмотра шире, чем 600 пикселей, обратитесь к макету X.

Точки прерывания не ограничиваются шириной окна просмотра. Любая характеристика класса устройства может быть точкой прерывания: GPS (против отсутствия GPS), камера (против устройства без камеры) и т. п. Мы можем отметить эти точки на графике точек прерывания[124].

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

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

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

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

То, что мы здесь делаем, – это планируем прогрессивное улучшение. Цель такова: обеспечить как можно лучший опыт взаимодействия в контексте каждого устройства. Мы осуществляем это с помощью обеспечения самого основного опыта на самых основных устройствах (в некоторых случаях просто с HTML) и расширяем опыт через свойства, так как все больше и больше навороченных устройств и браузеров поддерживает их. Прогрессивное улучшение сводит до минимума риск, что продукт не будет вообще работать на основных классах устройств. Не все пользуются iOS. Такое планирование дизайна важно. Оно дает ценную информацию дизайнерам и разработчикам и шанс испытать удовольствие от свободы и скорости создания отзывчивого прототипа.

Рисунок 10.13. График точек прерывания для «Трех маленьких прямоугольников»

Вы могли слышать о практике проектирования в браузере. Должно быть, вы подумали, как и я: «Звучит великолепно, но только как я смогу сделать это быстро, когда дизайн еще не утвержден? Не похоже ли это на создание статических шаблонов на стадии разработки? Гораздо проще сделать макет в Photoshop». Но вот дилемма: мы хотим сделать что-то, что клиент может увидеть и одобрить, но мы не хотим начинать сейчас реальную разработку сайта.

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

Мы можем рассматривать эти HTML-макеты как развитие прототипов на основе веба. В этом случае прототип дает нам основу HTML для построения. Мы просто берем дизайн структурированного контента, вставляем его в шаблон, и мы на правильном пути к отзывчивому дизайну – прямо в браузере! Этот дополнительный плюс нам, что мы можем сразу протестировать дизайн на реальных устройствах на очень ранней стадии. Так как технологии развиваются, например дисплеи с высоким разрешением, расширяется брешь между веб-опытом и статическими изображениями, потребность в проектировании в браузере увеличивается.

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

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

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

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

Создание нашего дизайна в HTML и CSS дает следующие преимущества:

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

• Разработчики видят, где правильно, а где нет, с технической точки зрения. Как бонус они постигают процесс графического дизайна (если они не дизайнеры).

• Клиент и другие участники видят – и учатся принимать – разницу между браузерами и платформами. Когда они видят рождение своего проекта, они начинают понимать несколько больше о том, как работает веб и понимать ценность того, что сила веба заложена в контенте, правильно отображаемом на всех устройствах.

Полезно будет также показать клиенту скриншоты этих HTML-прототипов. Я делаю скриншоты в различных браузерах, с разной шириной окна просмотра и/или устройств[125] и говорю клиенту: «Вот несколько изображений того, как этот дизайн может работать в различных сценариях». Показ их сначала именно в качестве изображений помогает проводить обсуждение вопросов по дизайну и избежать глубинного анализа отдельных частей контента. Но если клиент хочет изменить стиль, допустим, «шапки», вы можете сделать это в CSS и сделать новые скриншоты очень быстро. Представьте, что вы делаете эти изменения в различных документах Photoshop – невесело! Клиент не заметит (или его не волнует) то, что эти изображения не созданы в Photoshop.

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

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

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

Многие дизайнеры эффективно используют метаязыки на основе CSS и/или препроцессоры или компиляторы, такие как SASS и LESS[126] для значимых изменений в CSS в относительно короткие сроки. В сочетании с контролем версий эти средства могут осуществлять разработку в браузере быстрее, проще и намного интереснее, чем работу в графическом редакторе. Апробирование Великой Новой Идеи клиента (или вашей собственной) становится обычным делом, а процесс может помочь вам держать проект «в тонусе» и сохранить бюджет, сократив объем работ, требующийся на освоение новых идей.

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

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

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

В конечном итоге разработка в браузере таким способом приносит огромную пользу:

• Мало или вообще нисколько времени не тратится на графические редакторы. Все время посвящается коду, который мог бы использоваться полностью или частично в процессе разработки самого сайта. Использование контроля версий наподобие Git позволит вам свободно экспериментировать со своим дизайном непосредственно в коде и не волноваться о постоянных изменениях.

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

• Демонстрация клиенту изменений состояний (например, авторизован или разлогинен пользователь) возможна с минимумом усилий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• шрифт.

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

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

Adobe Photoshop и Fireworks могут оказаться и не лучшими средствами для веб-разработки, но все же будут ценными для создания любого вида компонентов. Чтобы помочь вам избавиться от мыслей о разметке на данном этапе, попробуйте начать с холстов Photoshop и Fireworks, размеры которых составляют 10,000 на 10,000 пикселей и больше.

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

Трент Уолтон писал[140]:

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

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

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

• Насколько чистым или минималистичным должен быть дизайн?

• Как мы будем использовать цвет для передачи действий и смысла?

• Сколько будет шагов в тоне и контрасте?

• Как будут использоваться гарнитуры для различия типов контента?

• Сколько уровней будет в типографической иерархии?

Абстракция дизайна во впечатлениях и ощущениях от элементов – это нечто такое, о чем думает дизайнер Саманта Уоррен. Она называет эту технику мозайкой стилей.

[143]

Для других, элементы страницы могут быть компоновочными блоками для будущего дизайна. Возьмем Марка Отто и Джейкоба Торнтона – тандем дизайнеров-разработчиков, которые работают в Twitter. Эти двое стоят за Bootstrap[144]. Интернет может быть безграничным, но контент у него есть всегда. Мы выражаем этот контент через соответствующие HTML-элементы:

• заголовки и их уровни от 1 до 6;

• параграфы, цитаты и элементы на уровне текста;

• списки: определения, нумерованный и ненумерованные;

• медиа: диаграммы, заголовки и изображения;

• таблицы;

• формы: кнопки, элементы и метки.

Так же как у Twitter есть своя сетка, так и Bootstrap включает в себя дизайн по умолчанию для «типографики, форм, клавиш, меток, сеток, навигации и остального». Bootstrap интересен по ряду причин. Не только потому, что это мощный шаблон для разработки, но и потому что в нем есть полный список HTML-элементов, вместе с несколькими стилями по умолчанию, что является идеальной отправной точкой для нового дизайна.

Рисунок 11.1. Сначала вы должны узнать, почему такие средства разработчика, как Bootstrap важны для отзывчивого рабочего процесса. Возможно, вы удивитесь, когда узнаете, что Bootstrap – это великолепная исходная точка для разработки элементов страницы

Dribbble[145] – это сайт, где дизайнеры обмениваются маленькими скриншотами (максимум 400 на 300 пикселей) дизайнов, над которыми они работают.

Рисунок 11.2. Dribble показывает элементы в нейтральном окружении

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

Шоты сайта Dribbble – это прекрасные примеры разработанных элементов без разметки. Они показывают, как мы можем разработать дизайн и потом продемонстрировать нашим боссам и заказчикам направление дизайна в формате, который не путает стиль с расположением.

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

Рисунок 11.3. Global Experience Language (GEL) – 18 документов полного визуального стиля для веба компании ВВС

Один из лучших приведенных примеров полного комплекта руководств по стилю «пришел» из BBC. Его руководство Global Experience Language (GEL)[146] документирует полный визуальный язык BBC для использования в Интернете, с подробной информацией о типографике, иконографике и дизайне элементов интерфейса, таких как наложение, «аккордеон» и карусель изображений.

E-mail-эксперт MailChimp[147] создал свою собственную библиотеку образцов пользовательского интерфейса, чтобы документировать то, как задается стиль таким элементам, как клавиши, формы, таблицы и табы (вкладки).

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

Вещи, подобные Bootstrap в Twitter, GEL от BBC и библиотеке образцов пользовательского интерфейса от MailChimp, – великолепные примеры дизайна элементов. Они детально описывают, как должен выглядеть каждый элемент, появляющийся в дизайне. И делают они это с небольшой ссылкой на разметку или вовсе без нее.

Самое детальное руководство по стилю не просто документирует дизайн сайта – оно само его дизайн. Поэтому зачем ждать окончания процесса до того, как сделать руководство по стилю? Вместо этого рассматривайте эти руководства как еще один пример дизайна на уровне элементов.

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

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

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

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

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

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

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

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

Давайте разобьем любой дизайн на его компоненты:

• Типографика: гарнитура, работа с текстом и пустым пространством;

• Цвет: для пробуждение настроения и операций выделения;

• Текстура: декоративные аспекты, в том числе рамки, затенение и фигуры;

• Разметка: горизонтальное и вертикальное расположение элементов по сетке.