Матчасть

Типографский калькулятор

Это веб-приложение привнесит в веб те возможности, которыми уже 500 лет пользуются в полиграфии и печатном деле.
— Джефри Зельдман (JEFFREY ZELDMAN), блог A List Apart

Ampersand NYC 2013 web type design conference

2 ноября на конференции Ampersand NY, посвященной типографике в вебе, Ник Шерман (NICK SHERMAN) представил свой калькулятор (SIZE CALCULATOR) для расчета реального размера шрифта в зависимости от дистанции чтения и визуально воспринимаемых габаритов текста.

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

Например,

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

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

Пусть экран смартфона находится на расстоянии 20 см от лица читателя. Фиксируем замочком третий параметр (воспринимаемый размер) и указываем в качестве дистанции новое значение.

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

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

Стандартный
Видео, Матчасть

Человеко-ориентированное проектирование: Теория и практика

Выступление Дмитрия Сатина для стартапов в API.Moscow.

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

Стандартный
Статьи

Основы адаптивной типографики

Автор: Оливер Райхенштайн (OLIVER REICHENSTEIN), 1 июня 2012
Оригинал: http://ia.net/blog/responsive-typography-the-basics/
Адаптированный перевод: Егор Стремоусов, 1 ноября 2013

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

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

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

  1. Адаптивный макет: пошаговое изменение макета под ограниченное число размеров экрана.

  2. Резиновый макет: когда макет использует всю доступную ширину экрана.

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

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

Выбор шрифта

Правильный характер

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

Мы разработали свой собственный шрифт для нашего сайта с целью проведения адаптационных экспериментов. Мы выбрали шрифт с засечками, поскольку это соответствует нашему характеру и отражает изысканность наших материалов (по крайней мере, нам так кажется). Для iA Writer мы использовали моноширинный шрифт. Поскольку главной целью этого приложения является помощь в написании черновика, мы умышленно взяли Nitti — шрифт, который делает текст сильным и, в тоже время, аккуратным. Решение использовать моноширинный шрифт было продиктовано еще и тем фактом, что операционная система первого iPad не имела автоматического кернинга для пропорциональных шрифтов. Вместо того, чтобы использовать пропорциональный шрифт, который будет плохо смотреться, мы решили запустить приложение в жизнь с моноширинным шрифтом.

С засечками или без?

Обычно жребий падает между шрифтом с засечками и шрифтом без засечек. Сам по себе это сложный вопрос, но есть одно правило, которое может вам помочь: «Шрифт с засечками — это священник, а без засечек — хакер». Это не значит, что один лучше другого. Нет, просто по ряду причин антиква лучше передает авторитарные ощущения, а гротеск более демокартичен. Учтите, что пять тысяч лет типографского дела уместились в одно это кривое определение, поэтому не стоит относится к нему слишком серьезно.

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

Какой размер?

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

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

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

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

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

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

Высота строки и контраст

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

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

iPhone vs iPad

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

Если вы сравните текущую версию iA Writer для iPhone с версией для iPad, вы можете заметить, что размер шрифта в них разный.

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

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

  2. Экран iPhone меньше, и приходится учитывать это ограничение.

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

Поскольку iPhone преподносится к лицу ближе, а размер экрана у него меньше, то высота строки также уменьшается:

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

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

А что с настольными компьютерами?

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

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

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

Хорошо, но почему бы тогда не подстраиваться под разрешение экрана автоматически? Не будет ли это действительно адаптивной типографикой? Все верно, и мы уже работаем в этом направлении. Но сейчас, помимо адаптации к разрешению экрана необходимо также выбирать правильный оптический вес текста, чтобы быть уверенным, что шрифт работает именно так, как и задумывалось, во всех размерах и разрешениях. С изменением размера шрифта поменяется также и оптическое восприятие текста. Вот почему версии iA Writer для Mac, iPad 1/2 и iPad3 отличаются друг от друга. Чтобы объяснить логику адаптации шрифтов полностью, а также наши соображения, которыми мы руководствовались при разработке нового сайта, мне потребуется немного больше времени и пространства. Так что ждите продолжение!

Отзывы

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

«@iA Дочитал до фразы „проектирование взаимодействия — это инженерная деятельность“. Что это значит?» @bokardo

На случай, если кому-то еще будет интересно… Полная цитата звучит так:

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

Обычно я говорю:

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

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

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

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

Резюмируя, можно сказать, что в процессе проектирования сайтов и приложений, большую часть времен мы думаем о компромиссах и выбираем из всех зол наименьшую. Это то, что выбивает большинство графических дизайнеров из колеи, поскольку они привыкли к тотальному контролю. Больше информации об этом вы можете почерпнуть в великолепной презентации Чои Вина (KHOI VINH) «Разница между графическим и экранным дизайном» (2007).

Стандартный
Видео, Матчасть

Человеко-ориентированное проектирование сайтов

1 октября 2013 года состоялась кейс-конференция «Как мы делаем такие сайты», организованная аналитическим порталом рынка веб-разаработок CMSMagazine.

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

human centered design

Согласно этому подходу, проектировать следует в таком порядке:

  1. Стратегия дизайна
  2. Портрет потребителя (персонаж)
  3. Сценарий взаимодействия
  4. Прототип (макет)
  5. Проверка (тестирование) прототипа

При этом в стратегии дизайна следует рассмотреть, четко прояснить и зафиксировать следующие вещи:

  1. Цели
    Для чего это все делается?
  2. Целевая аудитория
    Для кого это делается?
  3. Маркетинг (откуда они узнают?)
    Какие каналы и способы привлечения внимания будут использоваться?
  4. KPI (показатели успеха)
    Количественные и качественные, отслеживаемые результаты работы сайта

Портрет потребителя формируется из:

  1. Профиль
    Возраст, пол, место проживания и т.д.
  2. Потребности (мотивы)
    Какие у него проблемы?
    К чему стремимся?
    Жизненная ситуация
  3. Цели (образ результата)
    Что ему нужно, чтобы решить проблему?
  4. Поведение
    Как он решает проблему без нас?
    Как выглядит его день (жизнь)?

Для разработке сценария взаимодействия необходимо

  1. Выписать шаги решения задачи при помощи сайта
    Что спрашивает потребитель?
    Что отвечает сервис (поставщик)?
  2. Думать о людях, а не сайтах!

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

Какие проблемы ждут потребителя?
Что может не хватать потребителю для получения услуги?

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

Любой жаждущий более подробных нюансов процесса человеко-ориентированного проектирования может углубится в ГОСТ Р ИСО 9241-210—2012 «ЭРГОНОМИКА ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕК—СИСТЕМА. Часть 210: Человеко-ориентированное проектирование интерактивных систем» (ISO 9241-210:2010 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems (IDT)).

***

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

Благодаря специально созданной структуре Government Digital Service, в этой стране формируется и культивируется правильное взаимодействия человека и государства в цифровой среде. Чего только стоят разработанные этой командой принципы дизайна!

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

UPDATE: Сайт Минкомсвязи о планах по повышению качества жизни на 2012-2018 годы.

***

P.S. Бонус для самых терпеливых, для тех, кто смог осилить пост до конца. Собственно, само видео выступления Дмитрия Сатина, а также еще 11 докладов из секции Как мы делаем государственные сайты 🙂

Стандартный
Матчасть

Дизайн и юзабилити интернет-магазина

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

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

Стандартный
Статьи

Секретная симфония: подробное руководство по удобочитаемой типографике в вебе

Автор: Крис Пирсон (CHRIS PEARSON), декабрь 2011
Оригинал: http://www.pearsonified.com/2011/12/golden-ratio-typography.php
Перевод: Егор Стремоусов (28 декабря 2011)

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

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

Математическая симфония типографики

Как известно, эта симфония не прерогатива веба. Вы «слышите» ее каждый раз когда читаете книгу, газету, журнал или сайт — что угодно, что содержит типографику.

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

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

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

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

Вывод из этого:

Математические пропорции типографики — это жизненно важный фактор для восприятия сайта и его содержания.

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

Три фундаментальных типографских параметра

Каждый параграф текста, который вы видите, имеет 3 основных измеряемых параметра. Первые два, размер шрифта и высота строки — измеряются по вертикали.

Рисунок 1 — Как размер шрифта и высота строки представлены в браузерах.
Размер шрифта — это расстояние от верней точки заглавной буквы (S) до нижней границы нижних выносных элементов (y). Высота строки делится пополам и равномерно распределяется сверху и снизу от центра строки.

Третий параметр, длина строки, измеряется по горизонтали.

Рисунок 2 — Высота и длина строки — это вертикальная и горизонтальная метрики типографики.

Эти три параметра вместе определяют то, как вы воспринимаете текст.

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

Ниже, на рисунке 3, высота и длина строки зафиксированы, а размер шрифта изменяется от 13 до 16 пикселей.

Рисунок 3 — С фиксированными высотой и длиной строки становится ясно, что чем большие размер шрифта, тем больше требуется высота строки для сохранения пропорций и удобочитаемости.

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

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

Размер шрифта и высота строки имеют прямо пропорциональную зависимость.

В следующем примере размер шрифта и высота строки фиксированные, а длина строки варьируется от 233 до 466 пикселей.

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

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

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

Эти выводы подтверждают проведенные исследования. В 2004 году Мэри Дайсон (MARY C. DAYSON) из Института Чтения (какая ирония, да?) установила, что:

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

Что это значит для нас? Это означает, что высота и длина строки имеют определенную математическую зависимость, а конкретно:

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

Но каков математический смысл этого соотношения?

Гармоничные пропорции и золотое сечение

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

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

Что же это за удивительные пропорции, которые «склеивают осколки этого мира»?

Конечно же, я говорю о золотом сечении.

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

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

Так, может быть, золотое сечение применимо для решения этой задачи?

Математика золотого сечения типографики

Как вы уже, наверное, догадались, ответом является решительное «да»! И вот как это работает.

Во-первых, размер шрифта (f) и высота строки (l) соотносятся через коэффициент подобия (h). Базовое математическое уравнение выглядит следующим образом:

Согласно этому уравнению, оптимальная высота строки получится в том случае, если коэффициент подобия h будет равен золотому сечению φ. Это дает нам следующее уравнение:

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

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

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

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

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

Эти уравнения примечательны тем, что впервые подводят под параметры текста прочную математическую основу.

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

Однако, тут есть небольшая проблема: веб не настолько точен, как эти уравнения.

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

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

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

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

Тонкая настройка золотого сечения типографики для веба

Чтобы понять, как выпоняется корректировка, давайте рассмотрим пример.

Для шрифта с размером 16 пикселей идеальная высота строки получается тогда, когда коэффициент h равен золотому сечению (≈1.61 — Прим. переводчика). Это дает оптимальное значение для высоты строки, равное 25.88854 пикселя. Используя это значение, вы можете вычислить, что соответствующее оптимальное значение для длины строки равно 670.21670 пикселя.

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

Поскольку разрешены только целочисленные значения, веб не сможет отобразит высоту строки, равную 25.88854 пикселя. В лучшем случае высота строки станет равна 26 пикселям.

Но 26 пикселей — это больше, чем оптимальная высота строки, полученная из уравнения. А как мы уже знаем, нельзя изменять высоту строки (даже на чуть-чуть!) без изменения соответствующей длины строки (в противном случае конечные пропорции не будут «золотыми»).

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

Эту суть корректировки параметров типографики:

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

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

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

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

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

  1. скорректированную высоту строки, зная размер шрифта и длину строки;

  2. или скорректированную длину строки, зная размер шрифта и высоту строки.

Вычисления проводим при помощи следующих уравнений:

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

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

А теперь давайте рассмотрим другой, более насущный пример, который покажет как вы можете подправить типографику на вашем сайте прямо сейчас:

  • Что, если вы захотите использовать шрифт в 16 пикселей для текста шириной 550 пикселей?

  • Какой должна быть высота строки в этом случае?

Вы можете решить эту задачу следующим образом:

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

Калькулятор золотого сечения типографики

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

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

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

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

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

Если вы укажите и размер шрифта, и длину строки, то получите целый набор:

  • Оптимизированные параметры типографики для вашего размера шрифта и длины строки.

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

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

  • Оптимальные значения типографики для указанного размера шрифта.

Попробуйте поиграть с калькулятором золотого сечения и познайте невиданное качество типографики!

Особое значение золотого сечения типографики

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

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

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

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

Заключение

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

Запомнили математическую симфонию типографики?

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

Стандартный
Статьи

О верстке вертикального ритма

Ритм в теории музыки — соотношения длительностей
звуков (нот) в их последовательности.

— Википедия

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

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

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

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

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

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

Расчет интересующей нас высоты линейного блока происходит по следующему алгоритму:

  1. Определяется высота каждого строчного блока в линейном блоке.

  2. В соответствии со свойством vertical-align строчные блоки выстраиваются по вертикали.

  3. Определяется высота линейного блока как расстояние от верхней границы самого верхнего строчного блока до нижней границы самого нижнего блока.

Следует помнить, что пустые строчные блоки так же влияют на расчет высоты линейного блока, поскольку, несмотря на отсутствие содержимого, имеют внутренние и внешние отступы (padding и margin), границу (border), высоту строки (line-height), а также заданные размеры (width и height).

Таким образом, значимыми CSS-свойствами для расчета высоты линейного блока являются:

  • padding-top, padding-bottom

  • margin-top, margin-bottom

  • border-top, border-bottom

  • height

  • font-size

  • line-height

  • vertical-align

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

Padding, margin, border

Свойства padding-top, padding-bottom, margin-top, margin-bottom, border-top и border-bottom не увеличивают высоту строчного блока на собственное значение, однако учитываются при расчете высоты линейного блока.

Height

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

Line-height и font-size

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

Важно понимать, что свойства line-height и font-size связаны между собой понятием интерлиньяжа.

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

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

Vertical-align

Свойство vertical-align смещает строчные блоки внутри линейного блока по вертикали, «растягивая» его высоту

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

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

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

Пример из жизни

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

Для определения требуемых стилевых правил воспользуемся упомянутым выше (или любым другим) генератором вертикального ритма.

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

Причина проблемы в выравнивании по базовой линии (навязано набором правил из reset css) и фиксированном line-height (определен генератором). Уменьшение размера шрифта ведет к увеличению половинного интерлиньяжа и к смещению второго строчного блока вниз, что, в свою очередь, приводит к увеличению высоты линейного блока.

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

Ссылки по теме

Генераторы вертикального ритма:

http://topfunky.com/baseline-rhythm-calculator/
http://drewish.com/tools/vertical-rhythm
http://toki-woki.net/p/Boks/
http://baselinecss.com/

Рекомендуемые к прочтению статьи о верстке вертикального ритма:

http://www.alistapart.com/articles/settingtypeontheweb
http://webtypography.net/Rhythm_and_Proportion/Vertical_Motion/2.2.1/
http://24ways.org/2006/compose-to-a-vertical-rhythm
http://thegrids.ru/literature/31
http://habrahabr.ru/blogs/typography/78322/

Стандартный
Видео

Дмитрий Сатин на WUD-Минск’2011

Из описания на Youtube:

Философский взгляд на нашу профессию. Как выглядит мир глазами юзабилиста? Что представляют собой Ад и Рай для юзабилиста? От чего он переживает уныние? А от чего приходит в восторг?

Стандартный
Статьи

Превентивный AJAX

Заработался, блин.
Залез на порно-сайт…..
Забыл, зачем залез, и начал выкачивать исходники их страниц, дабы посмотреть как у них реализован Ajax на сайте =(

— bash.org.ru/quote/393929

Про технологию AJAX широко заговорили в далеком 2005 году после запуска сервиса Google Maps и Google Search Suggestions. Тогда же с легкой руки Adaptive Path и Джесси Гаррета (JESSE JAMES GARRET) появился и сам термин «Асинхронный JavaScript и XML». Сокращенно — AJAX.

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

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

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

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

В сети появилось множество статей, раскрывающих всю «сложность» кроссбраузерной реализации «новой» технологии (96 года). Полки магазинов быстро заполонили книги типа «AJAX и PHP», которые несомненно покупались и окупались. Этот информационный бум в свою очередь породил толпы «программистов на АЯКСЕ», которых по убогости можно сравнить разве что только с «программистами на jQuery».

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

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

Апогеем AJAX-эпопеи можно назвать дыры растерянности в головах обычных людей, оставшиеся после hash-bang-модификаций и без этого не всегда понятных URL-ов. Парадигму полностью скриптовых сайтов подхватили мастодонты интернет-пространства типа Twitter’а и сервисов Google, задав курс и темпы развития для игроков поменьше.

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

Технология переросла в моду.

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

Хочется спросить, а где же реальная польза от AJAX?

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

Но ведь это все не видно нашим клиентам, не так ли?

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

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

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

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

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

Стандартный
Практика

3.12 Дополнительные сценарии

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

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

Это смена тарифного плана и оплата услуг при помощи бонусной системы провайдера.

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

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

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

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

Дополнительные сценарии

Исходя из представленных ограничений, составим дополнительные сценарии:

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

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

Иван предпочитает покупать ежемесячную скидку в 10% для своего тарифа. Система ежемесячно (перед списанием средств со счета) в автоматическом режиме списывает необходимое количество бонусов.

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

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

Люся тратит бонусы на розыгрыши и другие цели. Она не использует их как средство оплаты интернета.

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

Стандартный
Статьи

Адаптивный веб-дизайн

Автор: Этан Мэркотт (ETHAN MARCOTTE)
Иллюстрации: Кевин Корнэлл (KEVIN CORNELL)
Оригинал: http://www.alistapart.com/articles/responsive-web-design/ (25 мая 2010)

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

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

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

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

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

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

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

Мы можем изолировать мобильные версии сайтов по разным поддоменам, отдельно огородить «сайты не под iPhone». Но что дальше? «Сайт под iPad»? «Сайт под N90»? Можем ли мы на самом деле продолжать брать на себя обязательства по поддержке каждого нового устройства с уникальными параметрами взаимодействия?

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

Гибкая основа

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

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

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

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

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

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

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

Начинаем реагировать

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

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

В своей книге «Интерактивная архитектура» Майкл Фокс (MICHAEL FOX) и Майлс Кемп (MILES KEMP) описывают этот более гибкий способ организации пространства как «многозвенную систему, к которой кто-то подключается для общения; постоянный и конструктивный обмен информацией».

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

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

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

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

Знакомьтесь, это — Media Query

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

<link rel="stylesheet" type="text/css" href="core.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

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

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

Следует поблагодарить W3C за то, что он включил media queries в состав спецификации CSS3, тем самым улучшив перспективность media types. Media queries позволяют нам ориентироваться не только на определенный класс устройств, но и в режиме реального времени проверять их физические характеристики.

Например, после недавнего роста и улучшения мобильного WebKit, media queries стали популярной клиентской техникой отдачи специализированных таблиц стилей для iPhone, Android-телефонов и ему подобных. Чтобы добиться этого, мы можем добавить media query в атрибут media для соответствующей таблицы стилей:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />

Media query состоит из двух частей:

  1. media type (screen)
  2. и, собственно, сам запрос в скобках, содержащий конкретную media feature (max-device-width) и ее точное значение (480px) для проверки.

Мы как бы спрашиваем устройство о том, меньше или равно его разрешение по горизонтали (max-device-width), чем значение в 480 пикселей.

Если тест пройден успешно (т.е., мы просматриваем верстку на устройстве с маленьким экраном, как, например, у iPhone), то устройство подгрузит себе файл shetland.css. В противном случае ссылка на эти таблицы стилей будет проигнорирована.

Дизайнеры и раньше экспериментировали с макетами, поведение которых зависело от разрешения экрана. В основном эти опыты опирались на такие JavaScript-решения, как великолепный скрипт Кэмерона Адамса (CAMERON ADAMS).

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

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

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />

Кроме того, мы не ограничены в добавлении media queries только в тег link. Мы можем добавить их непосредственно в CSS-код, как часть правила @media:

@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

Или как часть директивы @import:

@import url("shetland.css") screen and (max-device-width: 480px);

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

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

Адаптация, реакция и преодоление

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

.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
width: 31.121642969984202211%;             /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}

Я специально опустил ряд типографических свойств, чтобы сфокусироваться на блочной модели. Каждый элемент с классом .figure занимает примерно треть от ширины родительского контейнера. К тому же последнее изображение в каждом ряду имеет нулевой правый внешний отступ (li#f-mycroft, li#f-winter).

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

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

@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

Если вы посмотрите на новый вариант страницы с нашим примером в современном браузере, при этом сделав ширину окна менее 600 пикселей, то media query отключит свойство текучести у основных структурных блоков и поставит их в одну линию друг над другом.

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

@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 48.341232227488151658%;          /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

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

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

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

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

@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 13.902053712480252764%;          /* 88px / 633px */
}
}

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

Указав большее значение для min-width в новом media query,
мы можем расположить наши изображения в один ряд.

И это только начало.

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

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

Но адаптивный дизайн не ограничивается изменениями в раскладке страницы. Media queries позволяют нам заниматься невероятно тонкой настройкой этих изменений. Мы можем:

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

Технические моменты

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

Браузеры Safari 3+, Chrome, Firefox 3.5+ и Opera 7+, а также Opera Mobile и мобильный WebKit, имеют встроенные парсеры media queries (в старых версиях этих браузеров такой поддержки нет). И хотя Microsoft взяла на себя обязательства по поддержке media queries в 9 версии Internet Explorer, на данный момент их реализацией этот браузер похвастаться не может*.

*На момент написания статьи Internet Explorer 9 еще не вышел в релиз. В 9-ойверсии браузера от Майкрософт обещанная поддержка была полностью реализована. — Прим. переводчика.

Однако, если вас интересует реализация поддержки возможностей media queries в старых браузерах, то вот вам JavaScript-овые лучики надежды:

  • jQuery-плагин 2007 года выпуска предлагает несколько ограниченную реализацию media queries, в которой используются только свойства min-width и max-width, добавляемые в тег link.
  • Недавно разработанная библиотека css3-mediaqueries.js, которая обещает «научить IE 5+, Firefox 1+ и Safari 2 парсить, тестировать и применять CSS3 Media Queries» путем подключения их через блоки @media. Несмотря на то, что версия библиотеки еще только «1.0», мне она показалась довольно стабильной, и я планирую следить за ее дальнейшей разработкой.

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

Только вперед

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

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

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

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

Об авторе

Этан Мэркотт — веб-дизайнер и разработчик, которого глубоко волнуют красивый дизайн, элегантный код, а также их взаимное пересечение. На протяжении нескольких лет Этан имел удовольствие работать с такими заказчиками, как the Sundance Film Festival, Stanford University, New York Magazine and The Today Show.

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

Его последняя книга называется «Адаптивный веб-дизайн».

Стандартный
Практика

3.11 Функциональные требования и информационная архитектура

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

Функциональные требования

Разрабатываемая система должна:

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

Превращаем выявленные функциональные требования в информационную архитектуру.

Информационная архитектура

1. Авторизация

  • логотип,
  • форма авторизации,
  • ссылки на главный сайт провайдера.

2. Сервисы

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

Данная информационная архитектура не окончательная и будет итеративно уточняться параллельно с созданием прототипа.

Стандартный
Матчасть

S.M.A.R.T-подход при постановке целей проектирования

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

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

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

Стандартный
Практика

3.10 Контекстные сценарии взаимодействия

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

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

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

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

Контекстные сценарии использования

  1. Иван становится клиентом компании «Сибирские Сети». При заключении договора в офисе компании (или сдаче приемке монтажных работ у Ивана дома) сотрудники провайдера сообщают ему о существовании биллинговой системы и ее преимуществах.
  2. При подключении Иван вносит свой первый платеж на свой счет в биллинговой системе. Если его подключение попадает под действие какой-либо промо-акции, он не вносит деньги на счет и пользуется определенный период времени услугами провайдера бесплатно.
  3. Провайдер выдает Ивану некий ключ доступа к системе. Иван может поделиться этим ключем со своей семьей или друзьями напрямую или опосредованно, разрешая им доступ к системе.
  4. Находясь дома, Иван знакомится с системой, получая от нее контекстную полезную помощь для новичков. В процессе знакомства система осуществляет собственную настройку для работы с Иваном самым удобным и предпочтительным для него образом.
  5. Система предлагает настроить автоматическое списание средств с любого стороннего счета Ивана за услуги провайдера. Иван указывает параметры своей зарплатной карты. Евгений разрешает системе доступ к своему интернет-кошельку в платежных системах Яндекс.Деньги и WebMoney. Люся ничего не указывает, поскольку предпочитает платить наличными.
  6. Проходит определенный период использования услуг и наступает момент, когда баланс счета Ивана начинает приближается к нулю.
  7. Первым делом система пытается самостоятельно сделать платеж, пытаясь списать средства с банковской карты Ивана. Эту операцию она совершает заблаговременно, рассчитывая, что для конца оплаченного периода остается не менее 3 дней.
  8. Списываемая сумма зависит от тарифного плана и равна ежемесячному платежу. Платеж проходит успешно, и система оповещает Ивана о переводе денег.
  9. У Евгения эта операция не завершается успехом, поскольку ни на одном из его электронных кошельков, проверенных системой последовательно, не оказывается достаточной суммы денег для списания. Система оповещает Евгения о невозможности совершить автоматический платеж и ожидает от него дальнейших действий.
  10. Евгений очень занят делами и не успевает вовремя внести деньги на счет в биллинговой системе, в следствии чего интернет у него отключается. Заметив отсутствие связи поздно вечером, Евгений решает совершить обещанный платеж, чтобы внести требуемую сумму на следующий день. Он заходит на страницу биллинговой системы и совершает обещанный платеж.
  11. На следующий день Евгений пополняет свой счет в одном из интернет-кошельков, снова заходит на страницу биллинговой системы и гасит задолженность. Система принимает платеж и сообщает экранным сообщением, что все прошло успешно.
  12. Когда баланс Люси подходит к критической границе, она получает уведомление о том, что скоро интернет может быть отключен. При этом она также сообщает ей, что мультикасса, через которую Люся привыкла вносить деньги, временно не работает.
  13. Люся обращается к системе за информацией о текущем состоянии счета и за помощью в поиске альтернативных путей оплаты. Система предлагает Люсе другую ближайшую мультикассу, которая точно работает. Люся узнает адрес и совершает внесение средств при помощи предложенной точки отплаты. Сразу же после проведения платежа система уведомляет Люсю, что ее он совершен успешно.
  14. Однажды летом Иван решает поехать в отпуск на целый месяц. Он обращается к биллинговой системе и указывает срок своего отсутствия. В указанный период система переходит в режим ожидания и не производит списание средств, а доступ к услугам провайдера блокируется.
  15. Иван возвращается немного раньше, чем планировал. Он вновь обращается к системе и переводит ее в нормальный режим функционирования.

***

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

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

Стандартный