Мне часто вспоминаются карты на стенах, которые показывают территорию офисного здания, торгового центра, метро или городскую зону, с выделенной обычно красной стрелой и пунктиром надписью «Вы здесь», указывающей на то место, где я стою. Эти карты показывают, где мы, что вокруг нас и куда нам надо идти. Конечно, нам нужно и то и другое. Мы должны четко знать направление, но это не имеет смысла, если мы не имеем понятия, где мы находимся сейчас.
Рисунок 10.1. Достичь места назначения важно, но знать отправную точку гораздо важнее. Фото: Джо Голдберг,
Карта все облегчает. Надпись «Вы здесь» показывает наше настоящее местоположение как данное; найти наш пункт назначения можно через индекс, а координаты посмотреть в таблице. Допустим, вы знаете, куда хотите пойти сначала. Тогда все, что вам остается, – это идти.
Философ Альфред Корзыбски заметил, что карта – это не территория: модель реальности – еще не сама реальность. Вот почему многие проектные планы не срабатывают. Не могу удержаться, но чувствую, в глубине души мы все это знаем. Примеры этого окружают нас везде: пробки, строительство дорог, улицы с односторонним движением, те вещи, которые мы не видели и не смогли бы увидеть на нашей карте, но мимо которых мы проходим.
Движение – это форма технологического рабочего процесса. Мы шныряем туда-сюда в транспорт, сокращаем путь, обходим стороной преграды, останавливаемся попить кофе, случайно сталкиваемся со старым другом и узнаем от него, что магазин, который мы ищем, находится уже в другом месте. Снова хватаем карту и корректируем план.
Технологический рабочий процесс должен быть плавным. Он должен приспосабливаться к различным обстоятельствам. Он должен быть… адаптивным, если хотите. Для нас, искателей шаблонов и любителей пошаговых руководств, нет ничего дороже, чем набор команд для нашего технологического рабочего процесса:
• пройдите прямо два квартала,
• поверните налево,
• пройдите еще два квартала,
• первое здание слева.
Это выглядело бы фантастически в том мире, где карта – это территория. Но так не бывает. Никогда.
Во-первых, мы часто не знаем, с чего нам надо начать проект. «Вы – здесь» не существует. Клиенты часто говорят нам: «Вы – здесь», но наша задача, как дизайнеров, спросить и выяснить, действительно ли это так.
Даже фраза «Я думаю, что мы здесь» – рискованное дело. Если вы хотите попасть в Нью-Йорк, а вы, скорее всего, в Париже, а не в Чикаго, у вас серьезные проблемы: машина, которую вы взяли в аренду, не лучший способ передвижения. Вам все-таки нужно добраться до Нью-Йорка, но это будет гораздо дольше.
Итак, технологический процесс должен оставаться подвижным, потому что любой фактор влияет на другие факторы. Комбинация исходной и конечной точек (пункт назначения или цель) определяет наш выбор для путешествия из пункта А в пункт В. Летите до Нью-Йорка самолетом, до отеля возьмите такси, до здания прогуляйтесь.
В веб-дизайне местность изменяется быстро. Польза от карт минимальна. В мультиплатформенном дизайне, где сайты и приложения будут использоваться на многих различных устройствах, мы сталкиваемся лицом к лицу с разнообразными пунктами назначения. Перечень устройств, которые нужно поддерживать, может быть нашей картой, но ее полезность в этом изменяющемся ландшафте ограничена. Мы не можем сказать: «Это должно хорошо выглядеть на Android», что это значит вообще? Возможно, вы столкнетесь со списком переменных, с которыми вам придется иметь дело: разрешение экрана, плотность пикселей, размер экрана, поддержка CSS (или вдобавок поддержка любой технологии), доступность, ввод через клавиатуру и мышкой против сенсорного ввода. Список можно продолжить. И это только технические факторы. Давайте не будем забывать о «туманных» (хотя все же технических) изменениях, например, почему у клиента сайт на устройстве BlackBerry выглядит иначе, чем в вашем макете Photoshop. Упс!
Итак, как же установить технологический процесс для создания или переделки нашего сайта так, чтобы оставаться гибкими и легко адаптироваться и при этом не блуждать туда-сюда? Первый и хороший шаг – это начать сначала. Давайте посмотрим, что мы имеем и откуда мы хотим начать наше путешествие. Для того чтобы обеспечить себе оптимальную гибкость, сосредоточимся сначала только на контенте.
Сначала структурированный контент: мышление, независимое от устройства или платформы
Намеренное игнорирование нашего пункта назначения и фокусирование на том, где мы есть и на самом ли деле хотим начать отсюда, требует от нас немалой гибкости. На сегодня одна из больших проблем Cети в том, что технологии влияют на принятие решений больше, чем следует. Возможности устройства становятся поводом для используемых функций. Система управления контентом выбирается еще до того, как мы решаем, что будет делать приложение и для кого оно. «Хотим использовать HTML5», – заявляем мы.
Естественно, что люди сосредотачиваются на технологии. Ведь технология – это захватывающая и такая классная забава. Веб-технологии – это игрушки, инструменты, всякие штуки, который используют «все». Вместо того чтобы дать нашей проблеме подвести нас к выбору правильной технологии для решения, мы смотрим на классные демоверсии и придумываем повод использовать их. Мы забываем о том, что эти демоверсии делают люди, которые…ну, делают демоверсии. Когда вы занимаетесь проектом редизайна, это реальная жизнь. Вам нужно сделать вещь, которая действует. «Круто» – это, конечно, хорошо, но только в том случае, если это работает и решает проблему. Сегодня все внимание слишком часто приковывается к решениям, а не проблемам. Нам надо на время превратиться в пессимистов и сосредоточиться на всех наших проблемах – сосредоточиться на них пристально, позволить им вырасти. Тем, кто имеет дело с веб-технологиями (т. е. вам), ответы придут на ум прямо в душе.
Перечень контента
Есть определенное мнение о контенте, которое поможет разработчикам (и их клиентам) сосредоточиться на реальной сущности проекта. На протяжении всего времени действительно имеют значение только две вещи – это основной контент и функциональные возможности сайта или приложения. В этом причина того, почему люди, в первую очередь, используют продукт. Не обращайте внимания на платформу. Игнорируйте браузеры. Сосредоточьтесь на причинах того, почему так. Назовем это мышлением, независимым от устройства или платформы, так как нас не волнуют эти вещи, по крайней мере, сейчас. Давайте применим это мышление к основному контенту и функциональным возможностям.
Как всегда, вопросы помогут нам мыслить критично:
1. Во-первых, почему люди будут использовать этот сайт? Найдите веские причины… Я не уверен. Поищите еще. А теперь «отшлифуйте» эти причины. Они должны быть истинными.
2. Если бы в мире существовал только один браузер, и он воспроизводил бы только язык HTML, со стилями по умолчанию и функциями, которые обрабатывает сервер, какую совокупность контента и функциональных возможностей вы могли бы предложить? Проще говоря, что смогли бы увидеть и сделать пользователи в таком случае?
Напишите ответы на эти два вопроса в список. Назовем его перечнем контента. Каждый элемент контента или функциональная возможность, которую вы будете добавлять в перечень, должен подходить под критерий цели: он должен активно поддерживать причины, которые вы внесли в список как ответ на первый вопрос.
Когда все сделано (это займет какое-то время и будет достаточно для промежуточного этапа разработки), посмотрите внимательно на результат. Он гласит: «Вы – здесь!»
В этом разделе мы расскажем о том, что можно изменить в технологическом процессе и в обычном веб-дизайне, чтобы в будущем сайт стал более удобным для пользователя. Мы поймем, как применять наш новый технологический процесс в простом проекте. Проект будет маленьким и умышленно не полным. Он просто покажет, как можно осуществить эти идеи. Попробуйте применить несколько или все техники в ваших личных проектах. Берите то, что работает для вас, и изменяйте или убирайте то, что не нужно. Я использовал все элементы в этом технологическом процессе в реальных проектах и остался доволен результатами. Надеюсь, что вы почерпнете из этих идей столько же полезного, сколько и я.
Пример: «Три маленьких прямоугольника»
Предположим, что мы работаем над сайтом, который обучает разработчиков CSS гибкой модульной верстке (или Flexbox), относительно новому модулю для разметки, которая имеет большие возможности в мультиплатформенном пространстве.
Смысл в том, чтобы объяснения и примеры были до смешного простыми. В силу того, что большая часть свойств CSS может объясняться текстом и несколькими прямоугольными блоками, назовем наш сайт «Три маленьких прямоугольника». Со временем мы можем расширить наши уроки и включить другие CSS-модули.
«Три маленьких прямоугольника» будут состоять из теории и синтаксиса, а также нескольких заданий, каждое из которых строится на основе предыдущего задания. Пользователь сможет написать их код в редакторе на странице, и кнопка «результат» покажет результат кода. Щелчком по клавише «Запустить» запускается введенный код. Каждое задание имеет два вида текстового контента: теорию и задание. Теория объясняет синтаксис и концепцию, а задания являются упражнениями, которые даются студентам для закрепления.
Давайте накидаем перечень контента:
1. Логотип.
2. Глобальная навигация.
3. Вводный текст (только на домашней странице).
4. Редактор кода (только на обучающей странице).
5. Область результата (только на обучающей странице).
6. Индикатор выполнения задания (только на обучающей странице).
7. Теоретический текст (только на обучающей странице).
8. Текст задания (только на обучающей странице).
9. Навигация урока (только на обучающей странице).
10. Регистрационная форма (только на домашней странице).
У нас есть два вида страницы:
• домашняя страница (для вводного текста и регистрационной формы) и
• обучающая страница.
Здесь остановимся. Понятно, что это до смешного просто и не завершено, но для примера хватит. Конечно, мы не включили сюда много другого материала (страницу профиля, статистику по урокам и т. д.) На большом сайте перечень контента может оказаться громадным и, возможно, разобьется на несколько частей. Но помните! Это не функциональные требования. Мы не должны включать каждую деталь каждой части контента. Мы разделили его на большие специфические группы, которые отражают суть.
Как правило, мы присваиваем, номерной или буквенныйидентификатор каждой части контента. Так как наш пример несложный, мы будем просто использовать нумерацию от 1 до 10, как в списке. Дизайн перечня не важен; годится простой старый текстовый файл. Но вы можете сделать его таким, каким позволит ваше воображение.
В перечне контента классно то, что он никогда не подведет. Все срабатывает. Клиент может выкрикивать все, что хочет, а вы просто записывайте это. Мы скоро выясним, что будет работать, а что нет.
Записи перечня можно украсить (например, описаниями или скриншотами готовых компонентов), но знайте меру. Я считаю, что расстановка соответствия контента и типов страниц очень полезна, так что:
• домашняя страница → 1, 2, 3, 10,
• обучающая страница → 1, 2, 4, 5, 6, 7, 8, 9.
Порядок позиций в данном случае не имеет значения. Мы займемся этим во время этапа прототипирования.
Прототипирование со ссылкой на контент
Один из первых шагов, которые делают многие из нас в веб-проектах (будем надеяться, что после тщательной инвентаризации контента) – это создание прототипов. Прототипы, которые сегодня разрабатывают в основном дизайнеры, эволюционировали от простых чертежей прямоугольников на холсте до почти полноценного веб-дизайна, разве что без цвета, изображений и подробной типографики. Изначально это были средства работы с дизайном: расположение блоков, эффект близости, визуальная иерархия, приоритет пространства и т. п. Контент был представлен «грубыми» блоками. Некоторые дизайнеры еще продолжают так делать. Но многие поменяли свои цели.
Сегодня прототипы часто представляются для показа клиенту, чтобы он посмотрел, как будет выглядеть сайт, и как он будет функционировать до фактической разработки. На самом деле эти прототипы и есть дизайн. Но они не доделаны, и поэтому их потенциально опасно показывать клиенту. Если клиенту нравятся его определенные аспекты, любое отклонение от них (шрифт ли это, цвет и т. д.) может привести к пропаже интереса со стороны клиента. Если дело закончится тем, что клиенту не понравится сам дизайн, что ж, тогда вам придется изрядно потрудиться.
Прототипы прошлых лет (впрочем, многие еще используют их) больше были похожи на наброски традиционных графических дизайнеров. Многие наброски могут делаться быстро, с адекватным объяснением того, что будет работать, а что нет. Дизайнерам нужно обратить внимание только на визуальную рельефность и композицию. Эти прототипы – их средство проектирования. Они не для клиента. Конечно, это не означает, что нельзя привлекать его на начальном этапе разработки, но делать это надо вскользь, для ознакомления, но никак не для утверждения нашей работы. Одобрение – это наименьшая проблема, которая может возникнуть, когда клиент решит сопровождать вас в процессе разработки.
Рисунок 10.2. Такой стиль прототипа обычен. Хотя, скорее всего, он и полезен, он здорово похож на реальный сайт, и только надпись «Прототип» выдает, что это не так. И визуальный дизайн, и контент подвергаются здесь детальной проработке, комбинация, которую возможно лучше обработать через прототип HTML, потому что создание нескольких вариаций для различных размеров экранов на такой ранней стадии проекта в лучшем случае будет нудным. Честно говоря, такая ранняя модель прототипа страницы из Википедии, возможно, служит своей цели. Но минусы для технологического процесса, дружелюбного к будущему проекта, очевидны.
Иллюстрация: Fabrice Florin, Wikimedia Foundation под лицензией CC-BY-SA и GFD /
Я называю эти уменьшенные модели «прототипами со ссылкой на контент». Если клиенту не понравятся ваши прототипы, вы потеряете всего лишь несколько минут работы. Цель такова: показать клиенту не «дизайн», а то, какой контент будет отражен в данном контексте, приблизительно обрисовав расположение и композицию, как предшествие визуальному дизайну. Это создает контраст с тем, как сегодня оформляются многие шаблоны, где графический дизайн уменьшается до размеров детской книжки-раскраски.
Создать прототип со ссылкой на контент несложно. Воспользуйтесь перечнем контента, определите, какое содержимое и функции должны быть на данной странице, а затем нарисуйте прямоугольники, в каждом из которых будут представлены эти части содержимого и функций.
Сделать это нужно для каждого типа страницы. Вы можете озаглавить каждый блок, или обозначить его буквой или номером в соответствии с пунктом в перечне контента. Вот и все. Совсем непривлекательно, но достаточно эффектно, особенно если мы не пытаемся навязать свой продукт клиенту.
Этот метод может показаться странным поначалу, но мы все еще на том этапе, где вычисляем, появится ли форма регистрации на странице, и ориентировочно прикидываем, в каком месте она была бы уместней. Мы должны просто подтвердить эти основные факты. Пока нет необходимости их визуализировать.
Прототипы со ссылкой на контент можно делать на бумаге или в графическом приложении. Но я подбиваю вас создавать их в HTML и CSS. Да, вам придется сделать несколько CSS-макетов, но это просто. Плюсы в том, что вы можете создавать прототипы, которые адаптируются под размеры экрана и позволяют вам принять решение об отзывчивости (адаптивности) дизайна на начальном этапе. Прототипы со ссылкой на контент могут разрабатываться так, чтобы прямоугольник имел фоновый цвет, а не просто очертания. И это хорошо. Типографические свойства тоже подойдут. Но делайте все в упрощенном варианте.
С этого момента прототипы становятся интереснее. Используя медиазапросы CSS, мы сможем начать работу над грубыми разметками для экранов различных размеров. Благодаря этому два наших прототипа превратятся в бесчисленное количество, потому что их так легко загрузить в браузер любого устройства. Потом мы сможем проанализировать возможности разметки и показать прототипы клиенту.
Я часто показываю клиентам скриншоты прототипов в различных размерах (чтобы не создать впечатление того, что процесс разработки будет скорым).
Но для самих себя просмотр прототипов на различных устройствах имеет свои преимущества.
Мы заверстали два прототипа (рис. 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 – это гибкий, универсальный конвертер:
В начальной точке создания прототипа, подумайте, как бы мы организовали наш контент, если бы не было никакой разметки, кроме линейной, той, что мы часто встречаем в мобильных версиях сайтов, когда один кусок контента располагается под другим. Эта философия «Сначала мобильные» («Mobile first»), которую популяризировал Люк Вроблевски, основывается на доступности и прогрессивном улучшении. Вы можете сказать, что цель заключается в разработке основного отображения приложения, которое функционирует достаточно хорошо везде, где может быть отрендерен простой 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, поэтому добавлять его мы сможем только для этих устройств.
Чтобы улучшить опыт взаимодействия структурированного контента, нам, как минимум, будет нужно составить список типов устройств, которые мы хотели бы поддерживать, группируя их в «классы» устройств. Проще говоря, сформируйте группу устройств с одинаковыми характеристиками, с тем чтобы сосредоточиться на классах устройств, а не на отдельных устройствах. Мы могли бы поддерживать только iOS или Android, но это уж было бы слишком ограничено. В результате мы можем наладить все так, чтобы приложение правильно выглядело и работало на любом устройстве.
Не классифицируйте в соответствии с основной физической формой, например такой как компьютер, смартфон, планшет и т. д. Эти категории важны менее, чем вы могли бы подумать. Вместо этого проанализируйте устройства (и заодно их браузеры по умолчанию) в соответствии с функциями, которые требует ваше приложение. Любой фактор может играть роль, будь то сенсорный ввод, размер экрана, пиксельное разрешение, геолокация, локальное запоминающее устройство, поддержка SVG и т. д.
Концентрация на свойствах гарантирует то, что наши решения останутся значимыми даже когда появляются новые устройства, которые трудно соотнести со средней потребительской и маркетинговой категориями. Маркетинговые категории не скажут нам о том, что нам нужно знать (например, существует ли поддержка SVG и хорошо ли она представлена в этом браузере и на этом устройстве).
Чуть ближе: классы устройств
Для сайта «Три маленьких прямоугольника» нам действительно нужно обратить внимание на классы устройств. Сайт будет образовательным и требует ввода кода пользователем, чтобы узнать, как он работает. Код будет интерпретироваться в браузере, а результат воспроизводиться на экране.
Давайте реально смотреть на вещи: провернуть все это на большинстве мобильных телефонов невозможно. В общем, вот классы устройств, с которыми мы будем иметь дело:
• с поддержкой HTML: необходима для обучающего текстового контента (теория и синтаксис);
• с поддержкой JavaScript: обязательна для интерактивных заданий;
• с большими экранами: не требуются для текстового контента, но удобны для упражнений;
• с кнопочной (неэкранной) клавиатурой: предпочтительна для набора кода;
• с браузером, который должен поддерживать последние спецификации Flexbox (иначе не будут работать упражнения).
Но у нас серьезная проблема. На момент написания этой книги новейшие спецификации Flexbox поддерживаются только в Chrome Canary, который ограничивает наши возможности работы с многочисленными устройствами. Если бы это был реальный сайт, мы бы столкнулись с тяжелым выбором. Предположим, мы не хотим создавать механизм разметки Flexbox в JavaScrip, мы застряли в Chrome Canary – единственном браузере, в котором будет исполняться код для задания.
Однако согласно нашему перечню контента и классам устройств мы точно можем обеспечить ценный текстовой контент (теория по Flexbox, синтаксис и т. п.), а потом уже предусмотреть интерактивные элементы, только если они на самом деле используются (т. е. когда требуемые функции доступны).
Определить лучший способ для этого очень сложно, и это выходит за рамки данного раздела. Но давайте представим, что мы используем JavaScript чтобы проверить, поддерживаются ли определенные свойства Flexbox в браузере. Если да, тогда интерактивные компоненты можно добавлять на сайт.
Улучшение опыта взаимодействия против ключевых сценариев
Когда мы доходим до фазы улучшения, мы должны спросить себя: «Эта функция настолько необходима для сайта в том виде, в каком она есть сейчас?» Если это так, тогда это то, что я и кое-кто еще любим называть «ключевым сценарием», т. е. это одна из базовых задач пользователя на сайте, которая в большинстве случаев не рассматривается как «улучшение».
Значит ли это, что улучшения несерьезны и не важны? Конечно же, нет.
Возьмем, к примеру, простое приложение для списка дел. Цель такова – сделать приложение используемым независимо от платформы; браузер должен только поддерживать HTML, включая основные функции для форм. Спору нет, что приложение списка дел должно позволять пользователю совершать по крайней мере несколько вещей:
• добавлять пункты дел,
• редактировать текущие пункты,
• отмечать пункты как выполненные,
• архивировать и удалять старые пункты.
Это наши ключевые сценарии. Конечно, мы могли бы реализовать больше (и многие приложения списков дел умеют больше), но пока давайте сосредоточимся на этих действиях, которые необходимы для целей приложения.
Одним словом, без JavaScript мы отображаем форму, которая содержит одно или несколько текстовых полей, куда пользователь может вводить один или несколько пунктов, а также клавишу для подтверждения. Содержимое формы посылается на сервер, перед пользователем появляется новая страница с их пунктами дел. Каждый пункт может иметь пару опций (возможно, в виде чекбоксов), и вы можете выполнять действия кликом на клавишу. Еще одно – данные должны передаваться на сервер и обратно, но по крайней мере это будет работать.
В любом браузере, который поддерживает JavaScript, мы хотим мгновенных действий: отметка задания как выполненного, возможно, сотрет текст и/или добавит галочку, а пользователь увидит изменения сразу же.
Это и не ключевой сценарий, и не бесполезное улучшение: это очень полезное улучшение, которое добавляет больше удобства использования нашему приложению. Зависимость от JavaScript не значит, что это плохо, только ее, возможно, следует избегать в определенных случаях.
И если этого можно избежать, почему бы тогда не начать с базовых функций на устройствах более низкого уровня? Помните, что многие неотразимые сайты с высоким трафиком, известные на сегодня, создавались, когда еще JavaScript не был распространен так широко. И все же эти сайты удовлетворяют потребности миллионов пользователей. Создать великолепный опыт взаимодействия без JavaScript вполне возможно. Огромное значение имеют контент, форма и исполнение, а не инструментальные средства.
«Три маленьких прямоугольника» представляет собой слегка иную проблему. Так как задания – это первичное использование сайта, есть определенная образовательная ценность в представлении четкой информации о спецификации Flexbox, ее синтаксиса и применения. Это не «все или ничего». Способность читать текстовую информацию – это тоже ключевой сценарий. Это текстовая информация содержит примеры кода и читается, как обучающее руководство.
Так или иначе опыт улучшается в Chrome Canary (вероятно, на настольных компьютерах и лэптопах), где интерактивные компоненты добавляются к заданиям. Это пример изменения контента на базе свойств устройства и браузера. Когда все сделано хорошо, пользователи неподдерживаемых платформ не ощущают потери важного контента.
Пользователь, у которого телефон семилетней давности, не будет ожидать того, что последний код на Flexbox, который он введет, воспроизведется верно. И также он не столкнется с нефункционирующими интерактивными компонентами.
Нам надо понять, где и когда представлять определенный контент и размещение. Я пользуюсь визуальным инструментом, который называю графиком точек прерывания. Он помогает мне отметить, где контент и дизайн могут изменяться.
График точек прерывания
Раньше мы рассматривали три вещи, которые хотели бы изменить по возможности для определенных классов устройств и/или размеров экранов:
• дизайн и расположение,
• функциональность и свойства,
• контент.
Точки, где эти изменения имеют место, называются точками прерывания. Они очень часто устанавливаются в отношении ширины окна просмотра в пикселях, в таких случаях они обычно вводятся в медиазапросы CSS и/или JavaScript. Например, вы могли бы сказать, что когда окно просмотра шире, чем 600 пикселей, обратитесь к макету X.
Точки прерывания не ограничиваются шириной окна просмотра. Любая характеристика класса устройства может быть точкой прерывания: GPS (против отсутствия GPS), камера (против устройства без камеры) и т. п. Мы можем отметить эти точки на графике точек прерывания.
График точек прерывания дает дизайнерам и разработчикам видение аспектов сайта, которые будут изменяться по определенным параметрам устройства. Эти изменения могут быть представлены уменьшенными прототипами (чтобы показать изменения в разметке) или метками, которые идентифицируют некоторые аспекты (чтобы показать изменения в функционировании и контенте). Мы можем отметить классы устройств (и даже специфические устройства) на графике точек прерывания. Это не только важно для группы разработчиков, но и позволяет клиенту увидеть, как сайт адаптируется в определенных условиях.
Сделать график точек прерывания достаточно быстро и легко. Он выглядит как временная шкала с горизонтальными линиями, представляющими полный спектр параметров. Эти параметры могут быть какими угодно: размером экрана, поддержкой специфических технологий или даже классом устройства.
Потом параметры группируются логически и располагаются над и под горизонтальной линией. Расположение параметров таким способом показывает, что их отношение друг к другу может быть полезным (например, класс устройства может совпасть с размером экрана), но такое не всегда возможно. После исследования, когда вы определили точки прерывания, каждая может быть представлена символом на линейке (мы использовали круг в примере ниже). Наборы свойств представляются прямоугольными затенениями за горизонтальной линией, охватывая точки прерывания среди которых они поддерживаются. Наброски миниатюр разметки для различных размеров могут быть включены под соответствующими точками прерывания.
Будьте осторожны! Установка точек прерывания для определенных устройств, хотя иногда это и требование, может вызвать проблемы. Изменения, которые вы делаете для платформы, могут хорошо выглядеть и хорошо работать на определенных устройствах, но, возможно, не на других с подобными функциями. По этой причине многие сайты сегодня используют функцию определения устройства.
То, что мы здесь делаем, – это планируем прогрессивное улучшение. Цель такова: обеспечить как можно лучший опыт взаимодействия в контексте каждого устройства. Мы осуществляем это с помощью обеспечения самого основного опыта на самых основных устройствах (в некоторых случаях просто с HTML) и расширяем опыт через свойства, так как все больше и больше навороченных устройств и браузеров поддерживает их. Прогрессивное улучшение сводит до минимума риск, что продукт не будет вообще работать на основных классах устройств. Не все пользуются iOS. Такое планирование дизайна важно. Оно дает ценную информацию дизайнерам и разработчикам и шанс испытать удовольствие от свободы и скорости создания отзывчивого прототипа.
Рисунок 10.13. График точек прерывания для «Трех маленьких прямоугольников»
Проектирование в браузере: Адаптивное и отзывчивое прототипирование
Вы могли слышать о практике проектирования в браузере. Должно быть, вы подумали, как и я: «Звучит великолепно, но только как я смогу сделать это быстро, когда дизайн еще не утвержден? Не похоже ли это на создание статических шаблонов на стадии разработки? Гораздо проще сделать макет в Photoshop». Но вот дилемма: мы хотим сделать что-то, что клиент может увидеть и одобрить, но мы не хотим начинать сейчас реальную разработку сайта.
Я сталкивался с этой проблемой очень долгое время, и решение менялось в зависимости от проекта. Я заметил, что если я начинаю работать в HTML на стадии прототипа, потом гораздо легче и быстрее расширить шаблон до полноценного визуального дизайна, чем в случае, когда я начинаю разработку с графического редактора. Те же плюсы, которые применяются для прототипов в HTML, действуют и здесь: вы должны работать с целевой технологией, и вы можете оценивать варианты (и показывать их клиенту), такие как изменения в ширине окна просмотра.
Мы можем рассматривать эти HTML-макеты как развитие прототипов на основе веба. В этом случае прототип дает нам основу HTML для построения. Мы просто берем дизайн структурированного контента, вставляем его в шаблон, и мы на правильном пути к отзывчивому дизайну – прямо в браузере! Этот дополнительный плюс нам, что мы можем сразу протестировать дизайн на реальных устройствах на очень ранней стадии. Так как технологии развиваются, например дисплеи с высоким разрешением, расширяется брешь между веб-опытом и статическими изображениями, потребность в проектировании в браузере увеличивается.
Мы увидели, что наш основной линейный дизайн на структурированном контенте лучше создавать в HTML и CSS, а причина в том, что мы начинаем расширять основной типографический дизайн в CSS. Мы будем загружать эти файлы в несколько браузеров на нескольких устройствах, чтобы видеть, что происходит и дорабатывать их.
Возможно, это выглядит как специальный дизайн, но это не так. Я не говорю о том, что вы пропустите проверенные этапы графического дизайна и скетчей. Мы всегда должны думать и делать наброски, прежде чем что-то выполнять на компьютере. Пожалуйста, продолжайте делать это. Я предлагаю выполнять проект или предложение для клиента в веб-технологиях, а не в графическом редакторе, таком как Photoshop.
Богохульство? Думаю, нет. Наши средства позволяют нам роскошь немедленной публикации. Каждый может создать веб-страницу за секунды. Вы не смогли бы это сделать в печатном виде. Когда работа выходит с печатного станка, существует легкое напряжение, как будто мы должны проверить, как все обернется. Почему мы настаиваем на разработке статических изображений, заставляя клиента утверждать их, и потом делаем ту же работу снова в HTML? Возможно, мы думаем, что дизайнеры не могут или не должны писать код. Спорный вопрос, который не является неминуемым препятствием. В худшем случае дизайнеры могли сделать свои наброски, а потом сесть с верстальщиком и создавать дизайн в браузере.
Короче говоря, мы можем пропустить этап использования графических редакторов для проектирования и использовать их отдельно для редактирования изображений, что имеет свой смысл.
Создание нашего дизайна в HTML и CSS дает следующие преимущества:
• Дизайнеры видят, что нужно отшлифовать в дизайне, чтобы он лучше выглядел в определенных браузерах и на определенных платформах. В качестве бонуса в процессе они узнают подробности о разработке в Сети.
• Разработчики видят, где правильно, а где нет, с технической точки зрения. Как бонус они постигают процесс графического дизайна (если они не дизайнеры).
• Клиент и другие участники видят – и учатся принимать – разницу между браузерами и платформами. Когда они видят рождение своего проекта, они начинают понимать несколько больше о том, как работает веб и понимать ценность того, что сила веба заложена в контенте, правильно отображаемом на всех устройствах.
Полезно будет также показать клиенту скриншоты этих HTML-прототипов. Я делаю скриншоты в различных браузерах, с разной шириной окна просмотра и/или устройств и говорю клиенту: «Вот несколько изображений того, как этот дизайн может работать в различных сценариях». Показ их сначала именно в качестве изображений помогает проводить обсуждение вопросов по дизайну и избежать глубинного анализа отдельных частей контента. Но если клиент хочет изменить стиль, допустим, «шапки», вы можете сделать это в CSS и сделать новые скриншоты очень быстро. Представьте, что вы делаете эти изменения в различных документах Photoshop – невесело! Клиент не заметит (или его не волнует) то, что эти изображения не созданы в Photoshop.
Рисунок 10.14. Взяв наш простой, структурированный контент в HTML, мы создали дизайн для него в линейной форме. Опираясь на скетчи, мы начали добавлять стили к нему. Потом, ссылаясь на наш график точек прерывания, мы сможем использовать медиазапросы, чтобы начать писать код для неимоверно больших экранов и браузеров, которые поддерживают наши желаемые свойства
Использование прототипов в виде изображений не говорит о том, что мы обманываем клиента. Скорее, это помогает избежать впечатления, что вы далеко продвинулись в разработке, когда на деле это не так. И это важно, потому что вы должны на данном этапе сосредотачиваться на дизайне. А к удобству пользования и внедрения обратитесь позже.
На самом деле, вы продвинулись далеко, но вашего клиента не должно волновать это. Следование технологическому процессу – это преимущество для вас и вашей команды. Клиент тоже останется доволен, когда сайт будет завершен, он будет выглядеть почти так же, как и в прототипе. Как вы будете разрабатывать прототип – это ваше дело. Некоторые генераторы статических сайтов могут приносить пользу: контент утверждается в файлах с разметкой Markdown, которые передаются по конвейеру через шаблоны, чтобы создать статический сайт. В конце концов, это просто инструменты. Вам все же придется сделать несколько шаблонов в HTML и CSS-файлов для дизайна. Если вы уже таким образом сделали исходные прототипы, то обычно контент распределяется по различным прямоугольникам на странице, к которым применяется CSS, основанный на ваших дизайнерских набросках.
Многие дизайнеры эффективно используют метаязыки на основе CSS и/или препроцессоры или компиляторы, такие как SASS и LESS для значимых изменений в CSS в относительно короткие сроки. В сочетании с контролем версий эти средства могут осуществлять разработку в браузере быстрее, проще и намного интереснее, чем работу в графическом редакторе. Апробирование Великой Новой Идеи клиента (или вашей собственной) становится обычным делом, а процесс может помочь вам держать проект «в тонусе» и сохранить бюджет, сократив объем работ, требующийся на освоение новых идей.
Когда клиент одобрит базовый дизайн, вы можете точно настроить и презентовать несколько важных страниц как полнофункциональных прототипов HTML в противоположность скриншотам. Это не сложно: вы проделали почти весь путь, так как ваш дизайн уже в HTML. Используйте это как свое преимущество, сосредоточьтесь на дополнительном дизайне: сообщения об ошибке, изменение состояния и т. п.
Сейчас у вас также есть время, чтобы рассмотреть эти вопросы, потому что вы пропустили шаг визуального анализа файла Photoshop и не вывели из него тонкости дизайна.
Все-таки не будем слишком жестоки к графическим редакторам. Приложения типа Photoshop прекрасно подходят для быстрых дизайнерских решений, работы с цветом и для проработки графических исходников. Используйте Photoshop для быстрых экспериментов с такими вещами, как цвет, фотография и кое-что из типографики. Photoshop хорошо работает для сбора карт настроений из всех этих элементов в их концептуальной фазе перед созданием дизайнерских впечатлений.
В конечном итоге разработка в браузере таким способом приносит огромную пользу:
• Мало или вообще нисколько времени не тратится на графические редакторы. Все время посвящается коду, который мог бы использоваться полностью или частично в процессе разработки самого сайта. Использование контроля версий наподобие Git позволит вам свободно экспериментировать со своим дизайном непосредственно в коде и не волноваться о постоянных изменениях.
• Выполнение многих требований клиента, как правило, история обычная (за исключением возможных изменений в макете). Эти изменения будут видны немедленно в окнах просмотра различной ширины и т. д. Делать такие изменения в редакторе – это огромная трата времени и ничего веселого.
• Демонстрация клиенту изменений состояний (например, авторизован или разлогинен пользователь) возможна с минимумом усилий.
• Если вы внимательно относитесь к качеству вашего кода на фазе разработки прототипа, многое из него пригодится для создания сайта.
Создание прототипа, как дизайна впечатлений и рабочего прототипа может показаться нелогичным, но я настаиваю, чтобы вы попробовали так сделать несколько раз, и вы привыкнете к идее. Это реально может сэкономить время. А вам никогда не нужно будет бросать свою целевую технологию. В отличие от традиционного процесса разработки сайта, она преподносит несколько сюрпризов.
Новое мышление, новый подход к дизайну
Давайте взглянем на наш новый технологический процесс:
1. Создать перечень, включив в список наш контент и функции.
2. Создать быстрые вайрфреймы в HTML и CSS, пометив прямоугольники в них соответствующим номером из перечня.
3. Используйте некоторое количество реального контента в структуре.
4. Создайте линейный дизайн для этого контента.
5. Рассмотрите классы устройств и создайте график точек прерывания.
6. Сделайте скетчи, обдумайте и составьте концепцию дизайна для различных точек прерывания.
7. Объедините контент из линейного дизайна и вайрфрейма на HTML, создавая дизайн в виде прототипа на HTML.
8. Покажите клиенту скриншоты прототипов, представляя их как графический дизайн.
9. После одобрения дизайна (необязательно) доработайте HTML-прототип и представьте его (например, для пользовательского тестирования).
10. Если все сделали правильно, большая часть кода может использоваться для создания сайта.
Этот технологический процесс эффективен как для переделки, так и для создания нового сайта. Это метод ориентированный на будущее, потому что мы рассматриваем различные классы устройств с самого начала. Поэтому новые устройства, которые появляются на рынке, не навредят сайту.
Этот технологический процесс эффективен, потому что каждый шаг нераздельно соединен с другим. И дизайнеры, и клиенты постоянно сталкиваются с реальными жизненными проблемами, такими как отображение в браузере.
Из своего опыта скажу, что клиентам нравится такой технологический процесс. Он не создает визуального напряжения так, как это бывает при традиционном дизайне технологического процесса, где продукция обрушивается как снег на голову. Он строится медленно, пошагово, клиент может включаться во весь процесс. Ничего удивительного. Каждый шаг приводит к более привлекательному результату по сравнению с предыдущим. Вещи конкретизируются очень быстро, а клиенты с самого начала видят эффект от своих решений. Некоторые дизайнеры и разработчики уже работают таким способом. Для некоторых, может быть, и для вас тоже, нужно время, чтобы привыкнуть. Попробуйте эти приемы в вашем проекте сегодня и откройте то, что работает для вас.
Возможно, процесс радикально отличается от того метода, которым мы привыкли работать, но это эффективный способ совершить путешествие как дизайнер Сети.
Об авторе
* * *
Стивен Хей (р. 1970) родом из Оранжа (штат Калифорния, США). Живет в городе Леуварден на севере Нидерландов. После получения степени бакалавра по графическому дизайну и изобразительному искусству он отложил в сторону свои мечты стать художником и прошел путь от дизайнера до арт-директора в дизайнерском агентстве, где специализировался на фирменном стиле и дизайне упаковки. Стивен сделал свой первый сайт в 1995 году и влюбился в веб. Сеть казалась ему идеальным сочетанием дизайна и технологий. После 10 лет работы креативным директором в фирме, связанной с веб-разработками, он стал независимым консультантом, и это дало ему больше времени для занятий любимыми делами. Ему нравится помогать людям учиться, он получает удовольствие, когда рассказывает или пишет про веб. Работа занимает не всю его жизнь: он играет на баритон-саксофоне и состоял в джазовом квинтете. Еще он любитель фокусов, искусства и кино. Важнейшие уроки, которые Стивен получил за свою карьеру: критически мыслить, заниматься тем, что доставляет удовольствие, делать все настолько хорошо, насколько ты можешь, и продолжать учиться.
О рецензенте
* * *
Брайан Ригер родился в год, когда распались «Битлз», Джими Хендрикс стал номером один, а население мира достигло 3,6 млрд человек. Он родом из Торонто и обычно большую часть года проводит в Эдинбурге, а оставшуюся часть старается провести в Бангкоке. Он довольно часто переезжал и рассматривал много мест в качестве своего дома, включая Шарлоттаун, Ванкувер, Сурабаю, Пхукет, Гонконг, Манилу, Лондон, Глазго и Брайтон. Дом там для него, где оказался сейчас, что хорошо сочетается с его жизненной позицией: «Удобно где бы то ни было!» Образование Брайана включает немного занятий дизайном, театром и анимацией в разных школах, в разное время и на разных уровнях. Брайан любит путешествовать, его любимый цвет белый, потому что он дает ощущение возможностей. Самый большой урок, который он получил за свою карье-ру, – спрашивать все и всегда. Его послание читателям: «Plus ça change, plus c’est la même chose („Чем больше меняются вещи, тем больше они остаются прежними“. – фр.). Будьте гибкими, принимайте перемены…»