3. 40
ПРОДУКТОВ
*
А еще – мобильные и планшетные сайты и приложения,
промо-страницы…
*
В нашем подразделении – почти половина
4. JESUS SAVES ГАЙДЛАЙНЫ
Как в короткий срок привести в порядок дюжину проектов? И
упростить будущую работу с группой сервисов?
Одна из наших главных задач – поэтапное обновление и
унификация этих продуктов вокруг нескольких гайдлайнов.
6. НАШ BOOTSTRAP
Мы создали дизайнерско-техническую платформу. Сейчас на
ней работает уже десяток проектов. К концу года
перезапустится еще пара-тройка.
10. ВЫЙТИ
ИЗ СВОЕГО УЮТНОГО МИРКА
Спецификации, единый исходник, библиотеки элементов и т.п.
– бесполезны на дистанции. Они в уютном дизайнерском
мирке и слабо востребованы разработчиками. Мы все знаем,
как часто «перевирается» дизайн на пути из макетов в
реализацию.
11. ТЕХНИЧЕСКАЯ УНИФИКАЦИЯ
*
Если один раз сделать код правильным и распространяемым –
гораздо больше поводов для уверенности в качестве дизайна,
работающего в реальном продукте.
*
Ключевое условие успеха при создании гайдлайнов.
14. Когда начинаем новый проект – проектируем все
необходимые экраны в InDesign. Этот прототип легко
провязывается ссылками и отлично работает на
устройстве, если экспортировать его в PDF.
Если какие-то блоки уникальны для нового проекта и
их еще не было во фреймворке – прорисовываем их в
Photoshop и после согласования добавляем в
библиотеку InDesign.
17. Из готовых компонентов собирается верстка всех
экранов в виде прототипа. Некоторые полностью
стандартизированы – например, комментарии или
фотогалереи.
Дизайнеры проверяют сборку перед запуском, если
нужно – дорабатывают макеты и логику
взаимодействия интерфейса. В работающей связке
всегда находятся нестыковки относительно
первоначального видения.
20. Шаблонизатор собирает итоговую верстку на лету из
отдельно сверстанных блоков, графики, стилей и
скриптов. Для всех типов страниц определяются
правила их сборки – т.е. набор блоков и их
последовательность.
Причем шаблон и данные для отрисовки конкретного
URL разделены и загружаются параллельно. Так что
если пользователь уже открывал эту страницу, у него
закэшируется ее верстка и в следующий раз будет
подкачиваться только контент.
23. Обновленный компонент меняется в макетах,
прототипе и базе кода. После этого каждый проект
обновляет его у себя из общего репозитория, почти
как приложения из AppStore.
При этом дизайнеру нужно проверить только одну
реализацию в единой базе кода вместо того чтобы
отслеживать каждый из сервисов. И можно быть
уверенным в качестве дизайна.
24. ДИЗАЙН
РАЗРАБОТКА
ОБНОВЛЕНИЕ
Информационная
архитектура
Перенос новых блоков в
базу кода
Редизайн блока
Проектирование всех
экранов интерфейса
Сборка проекта из
фреймворка
Обновление блока в UI
Kit
Дизайн недостающих
блоков
Подключение к API
основной версии
Обновление блока в
базе кода
Добавление новых
блоков в UI Kit
Запуск проекта
Обновление кода в
проектах из репозитория
25. РАДОСТЬ БЫТИЯ
Работать с фреймворком одно удовольствие – его развитие
идет легко, количество лишней работы снизилось до
минимума.
27. 2012
НАЧАЛО
*
В середине зимы началась работа по обновлению мобильных
сайтов для современных смартфонов.
*
Мобильная версия Почты появилась в 2004 году
28. 1.
ГЛАВНАЯ
Определили общий подход – карточки
для выделения блоков с разной
информацией, общая стилистика шапки
и заголовков, элементов управления и
т.п.
31. К счастью, Новости – самый простой из них. Там нет
никаких сервисных разделов кроме базового поиска и
комментариев – только текстовый и медийный
контент.
Нужно было продумать принципы навигации, способы
подачи контента и материалов по теме, компоновку
типовых страниц. Причем они должны учитывать и
будущие мобильные версии для других контентпроектов, которые должны быть созданы на основе
этого гайдлайна.
32. 3.
АФИША
Делали параллельно с главной. Масса
сервисов и достаточно сложная
структура. Интерфейсные решения
отличались от того что нам нужно для
Новостей, зато подача информации и
часть паттернов навигации пригодились.
33. ЮЗАБИЛИТИ-ТЕСТИРОВАНИЕ
Сделали много полезных выводов как для развития Афиши,
так и для представления контент-проектов на мобильных в
целом.
Например, востребованным оказалось дублирование поиска
внизу страницы. А во врезах-слайдерах последний элемент
должен вести на список всех объектов.
34. ПРОТОТИП В INDESIGN
Внешне похож на дизайн, но не повторяет его в мелочах.
Позволяет быстро собрать страницы нового проекта, не
привлекая дизайнера. Это разгружает его, да и просто
быстрее.
36. МАСШТАБИРОВАНИЕ ПАТТЕРНОВ
После первого же применения паттернов на новом проекте
возникло много вопросов к ним.
Например, экономить ли трафик или показывать в списках
иллюстрацию к каждому материалу? А что делать с
навигацией при разных масштабах?
*
И таких вещей – десятки
*
37. Подход к разделению блоков без
использования карточек показал ряд
проблем – сложно работать с длинными
страницами, контент которых зачастую
слишком разнороден.
От карточек отказались и в iOS7 и я
уверен, что это мешает работе со
сложными экранами – сложнее понимать
принцип группировки элементов.
39. Также важно помнить, что значительная
часть пользователей заходит на контентпроекты по ссылке с главной страницы
Mail.Ru на конкретный материал, а часть
– ходит по ним с главной страницы
проекта.
Куда в этом случае должна вести кнопка
«Назад» в интерфейсе?
40. UI KIT В PHOTOSHOP
После того как в дизайн-макетах были показаны ключевые
страницы, дизайнер предложил собрать их в одном файле для
упрощения дальнейшей работы.
Должен был получиться простой UI Kit, позволяющий быстрее
дорисовывать остальные экраны проекта.
41.
42. ГАЙДЛАЙН
Мы решили пойти дальше и собрать гайдлайн в дополнение к
нему – к задаче должны были подключиться другие
дизайнеры. Да и разработчики должны на что-то ссылаться
при сборке проекта.
43. Общая стилистика
Визуальное оформление
Сетка
Цвета и текстуры
Типографика
Иконки
Взаимодействие
Навигация
Жесты
Скроллинг
Выделение
Перетаскивание
Уведомления
Типовые элементы
Базовые компоненты экрана
Шапка страницы
Заголовок
…
Элементы управления
Уточнение поиска
Активное поле ввода
…
Навигация
Переключатель
Слайдер
…
Окна и диалоги
Попап
…
Списки
Социальный блок
…
Типовые экраны
Авторизация
…
Маркетинговые материалы
Баннеры
…
44.
45. 4.
ГОРОСКОПЫ
Важен был еще один проект для обкатки
гайдлайна. За исключением мелких
проблем стиль работал – адаптация
прошла быстро и легко.
46. ВАЖНО:
ОБКАТКА ГАЙДЛАЙНА
Перед тем как раскидывать унификацию на десяток проектов,
нужен пилот. Он позволит обнаружить проблемы в
концепции до того, как придется переделывать слишком
многое.
47. ИДЕЯ:
ТЕХНИЧЕСКОЕ РЕШЕНИЕ
У нас уже был механизм технической унификации –
например, портальная навигация и синяя шапка. А еще
многое делается для Почты, общепортальных попапов
авторизации и других частей интерфейса. Хотя технология
требовала серьезной доработки – целые продукты на ней еще
не запускались.
48.
49.
50. ТРЕБОВАНИЕ:
НЕЗАВИСИМАЯ ВЕРСТКА БЛОКОВ
Разработчики ушли детально исследовать задачу и смотреть,
есть ли готовые решения и продукты. В качестве общей
идеологии отлично подходил БЭМ (блок-элементмодификатор) от Яндекса.
51. Для унификации важно, чтобы одинаковые
интерфейсные блоки использовались на как можно
большем количестве страниц. Причем без
необходимости каждый раз перепроверять, все ли
хорошо на каждой из них.
БЭМ гарантирует независимость оформления
конкретного блока от того, что происходит вокруг
него. Это методология, для упрощения работы с
которой Яндекс создал open source-инструментарий
bem-tools.
*
Кстати, наши разработчики даже отправили несколько патчей в репозиторий проекта
52. Раньше зачатки этой технологии назывались «абсолютно независимые блоки», сейчас этим
подходом проникаются на Западе – например, фреймворки http://inuitcss.com и http://topcoat.io.
54. Наша технология работает на базе JavaScript и
используюет Node.js для выполнения кода на сервере.
Благодаря этому и на сервере, и у пользователя – один
и тот же шаблон страницы, который показывается
абсолютно одинаково.
Данные передаются отдельно от него. И когда шаблон
закэшировался в браузере после первой загрузки,
пользователю передается только контент, что сильно
сокращает объем трафика и скорость загрузки.
56. 2.5
МЕСЯЦА
12
ПРОЕКТОВ
Таких рекордов скорости мы еще не ставили. Гайдлайн
заметно вырос и описывал построение общего стиля и
многих конкретных блоков – множество навигационных
решений, списки, разные виды карточек, способы
представления контента, формы, попапы, диаграммы,
специфичные для конкретных проектов решения.
60. АВТОМАТИЗАЦИЯ ГАЙДЛАЙНА
Позволит отказаться от поддержки нескольких дизайнбиблиотек. Это генерируемая страница, в которую вместо
картинок подставляются реальные куски кода из фреймворка.
61. В таком виде куда проще проверять качество
реализации – в гайдлайне видны уже реализованные
блоки, а не их картинки-исходники, которые могут
быть неправильно заверстаны по пути из макетов. Там
же добавляется описание для каждого из них.
Пока этот документ существует в виде прототипа,
после перезапуска всех проектов на фреймворке мы
закончим его.
62. ПРОТОТИПИРОВАНИЕ В КОДЕ
С помощью этого автоматизированного гайдлайна можно
собирать прототипы из кусков готового кода, минуя InDesign –
это еще один способ стать ближе к конечной реализации.
63. ЛУЧШЕ, ЧЕМ BOOTSTRAP
Это набор готовых стилей и скриптов, а также примеры
верстки. И при обновлении фреймворка не так просто
перенести его изменения в свой проект – возможно, придется
подгонять верстку к новым правилам.
64. В нашем случае проект получает набор готовых к
использованию блоков, которые обновятся в проекте
при изменениях в фреймворке. К тому же Bootstrap не
придерживается модели независимых блоков, что
приводит к конфликтам – например, в связке Bootstrap
и jQuery UI они будут перебивать стили друг друга.
Правда, он и решает немного другие задачи – быстрый
старт проекта на готовых элементах. Хотя это же
является проблемой нашего, да и любого кастомного
решения – для его создания требуется больше
времени.
66. ПОДДЕРЖКА РАЗНЫХ ПЛАТФОРМ
• Современные смартфоны (Android, iPhone, Windows Phone)
• Старые смартфоны (Bada, Symbian)
• Кнопочные телефоны
*
Для старых браузеров на Android показывается немного упрощенная версия – они не тянут
многие из нужных нам визуальных эффектов.
*
68. СТАРЫЙ ДОБРЫЙ
ANDROID
Версия для Android имела более
заметные отличия, но мы упростили ее
чтобы не поддерживать еще один
вариант гайдлайна. Теперь единственная
разница – нет скругления блоков.
69. АВТОМАТИЧЕСКАЯ ДЕГРАДАЦИЯ
Сейчас запускается версия для современных смартфонов, на
очереди – остальные категории телефонов. Мы пытаемся
сделать деградацию до более простых версий автоматической
– поддерживать сразу три гайдлайна достаточно затратно.
70. ОДНОЯЙЦЕВЫЕ?
*
У такой унификации есть недостаток – полная одинаковость
дизайна ведет к отсутствию идентичности у проектов.
*
Это не так важно в мобильном вебе. Да и прямо сейчас, несмотря на то что мобильные активно
растут, проблема стоит не так остро.
71. СТИЛИЗАЦИЯ
ПРОДУКТОВ
В начале работы над фреймворком мы
опробовали несколько способов
стилизации продуктов. Это недорогой
способ дифференцировать их. После
перезапуска всех сервисов мы вернемся
к вопросу.
72. МОБИЛЬНАЯ ВЕРСИЯ –
НЕ УПРОЩЕННАЯ ДЕСКТОПНАЯ
Мобильная версия содержит весь контент и большинство
сервисов из основной.
Хотя для все большего количества пользователей нет понятия
«основная версия», для них то что они видят в своем
телефоне – и есть основная и единственная версия продукта.
73. Группа сервисов
Также через мобильные
Только через мобильные
Apple
54%
35%
Wikimedia Foundation
28%
21,6%
Amazon
27%
21,5%
Glam Media
21%
17,1%
CBS Interactive
17%
14,8%
Facebook
20%
14%
Google
16%
13%
Aol
13%
11,8%
Yahoo!
13%
11,4%
6%
5,4%
Microsoft
США, февраль 2013
http://allthingsd.com/20130325/among-big-properties-apple-and-amazon-have-greatest-portions-of-mobile-only-users/
75. ПОЧЕМУ НЕ ИСПОЛЬЗОВАЛИ
АДАПТИВНЫЙ ДИЗАЙН?
1. Слишком «тяжелая» по размеру версия для мобильных
при текущих технологиях.
2. Современные мобильные версии должны были появиться
как можно быстрее. Правильный адаптивный подход
требовал сначала унифицировать проекты в большом
вебе. Мы занимаемся этим, но задача сложная и долгая.
76. УНИФИЦИРОВАННЫЕ
ИКОНКИ
Мы бились над этим очень долго – во
всем мире задачу смог решить только
Яндекс и отчасти Google на Android. У
остальных все ограничивается эмблемой
в углу иконки.
79. Это еще один риск, на который нужно идти при
внедрении гайдлайна – приходится давить в себе
соблазны вносить разнобой в гайдлайн
осовремениванием отдельных частей.
Да, какое-то время они могут выглядеть несвежими.
Зато после запуска единой платформы обновлять
дизайн будет на порядок проще. Так что следующий
тренд после флэт-дизайна подхватывать будет легко и
быстро.
81. Нужно всегда использовать готовые паттерны. Если
вводится что-то новое – нужно пробовать подвести
под это решение уже реализованные проекты или
понимать, где оно пригодится в будущем.
Только тогда гайдлайн не расползется и
консистентность портфеля продуктов сохранится. А
значит сохранятся и удобство развития этих продуктов,
их комфортность для пользователя и положительный
эффект для всего бренда.
83. Гайдлайны – единственный способ контролировать большой
пул продуктов
Техническая унификация – единственная гарантия
консистентного дизайна. Выйдите из своего уютного
дизайнерского мирка
Нужен модельный дизайн, который станет прообразом
единого стиля. Лучше, если он уже запущен и минималььно
обкатан.
Важен пилотный запуск перед массовым распространением
гайдлайна. В начале вы ищете себя и правильные решения
Авторитаризм – залог консистентности гайдлайна
84. P.S.
*
Изначально требовалось просто обновить дизайн контентпроектов на мобильных и сделать их похожими. Идея полной
унификации, включая техническую часть, родилась по ходу
работы и общения с разработчиками. Дружите с ними
*
Не ждите указаний свыше, двигайте компанию вперед сами
85. CREDITS
ДИЗАЙН И ИНТЕРФЕЙС
РАЗРАБОТКА
АЛЕКСАНДР КИРОВ
АНТОН ЕПРЕВ
КОНСТАНТИН ЗУБАНОВ
АРСТАН ТОРЕГОЖИН
ГЕВОРГ ГЛЕЧЯН
АНДРЕЙ КУСИМОВ
ЕВГЕНИЙ БЕЛЯЕВ
ДМИТРИЙ БЕЛЯЕВ
АРТЕМ ГЛАДКОВ
БОРИС РЕБРОВ
ЮРИЙ ВЕТРОВ
ПАВЕЛ РЫБИН
ПАВЕЛ СКРИПКИН
ПАВЕЛ ВДОВЦЕВ
86. СПАСИБО!
ЮРИЙ ВЕТРОВ
www.jvetrau.com
twitter.com/jvetrau
All the illustrations used in this presentations are belong to their respectable owners. In case you are the owner and
don’t want to see them in my presentation – please email me to jvetrau@gmail.com and I’ll remove them.