1. УНИФИКАЦИЯ, VOL.1
Фреймворк Mail.Ru для мобильного веба
Юрий Ветров
Mail.Ru Group

2. О ЧЕМ ЭТА ИСТОРИЯ?

3. 40
ПРОДУКТОВ
*
А еще – мобильные и планшетные сайты и приложения,
промо-страницы…
*
В нашем подразделении – почти половина

4. JESUS SAVES ГАЙДЛАЙНЫ
Как в короткий срок привести в порядок дюжину проектов? И
упростить будущую работу с группой сервисов?
Одна из наших главных задач – поэтапное обновление и
унификация этих продуктов вокруг нескольких гайдлайнов.

5. №1
МОБИЛЬНЫЙ ВЕБ

6. НАШ BOOTSTRAP
Мы создали дизайнерско-техническую платформу. Сейчас на
ней работает уже десяток проектов. К концу года
перезапустится еще пара-тройка.

7. {
ЕДИНЫЕ:
ВИЗУАЛЬНЫЙ СТИЛЬ
ПРИНЦИПЫ РАБОТЫ
ИНФОАРХИТЕКТУРА
Удобно для пользователя – группа схожих продуктов работает
одинаково понятно и привычно.
Хорошо для бренда – вся линейка сервисов выглядит
целостной.

8. {
ПРОЩЕ:
ЗАПУСКИ
РЕДИЗАЙНЫ
Блоки и компоненты на все случаи жизни – можно быстро
собрать новый интерфейс.

9. ЛЕГЧЕ:
КОНТРОЛИРОВАТЬ
ПУЛ ПРОДУКТОВ
Они устроены одинаково. Вместо сотни отдельных проектов
нужно следить за парой гайдлайнов.

10. ВЫЙТИ
ИЗ СВОЕГО УЮТНОГО МИРКА
Спецификации, единый исходник, библиотеки элементов и т.п.
– бесполезны на дистанции. Они в уютном дизайнерском
мирке и слабо востребованы разработчиками. Мы все знаем,
как часто «перевирается» дизайн на пути из макетов в
реализацию.

11. ТЕХНИЧЕСКАЯ УНИФИКАЦИЯ
*
Если один раз сделать код правильным и распространяемым –
гораздо больше поводов для уверенности в качестве дизайна,
работающего в реальном продукте.
*
Ключевое условие успеха при создании гайдлайнов.

12. КАК УСТРОЕН
ФРЕЙМВОРК

13. 1.
«ПОЛОТНО» С ИСХОДНИКАМИ
Все блоки интерфейса и типовые экраны в PSD + библиотека
в InDesign.

14. Когда начинаем новый проект – проектируем все
необходимые экраны в InDesign. Этот прототип легко
провязывается ссылками и отлично работает на
устройстве, если экспортировать его в PDF.
Если какие-то блоки уникальны для нового проекта и
их еще не было во фреймворке – прорисовываем их в
Photoshop и после согласования добавляем в
библиотеку InDesign.

16. 2.
ЕДИНАЯ БАЗА КОДА
Все новые блоки попадают сюда.

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

18. touch.news/
blocks/
logotype/
logotype.png
bundles/
article
toolkit/
blocks/
logotype/
logotype.xml
section/
header/
Собираются из blocks и toolkit/blocks
Включает псевдо-бандл common.css

19. 3.
ШАБЛОНИЗАТОР
Он используется для показа конкретной страницы сайта в
браузере пользователя.

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

21. ОТРИСОВКА СТРАНИЦЫ НОВОСТИ
HTML
<style href=“common.css”>
<script>
var news = [
…
]
</script>
<script src=“template.js”>
CSS
common.css
homepage.css
article.css
document.write(template(news))
comments.css

22. 4.
ОБНОВЛЕНИЕ ГАЙДЛАЙНА
Если нашли новое решение для старого блока или
компонента – например, более удачный вид фотогалерей.

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

24. ДИЗАЙН
РАЗРАБОТКА
ОБНОВЛЕНИЕ
Информационная
архитектура
Перенос новых блоков в
базу кода
Редизайн блока
Проектирование всех
экранов интерфейса
Сборка проекта из
фреймворка
Обновление блока в UI
Kit
Дизайн недостающих
блоков
Подключение к API
основной версии
Обновление блока в
базе кода
Добавление новых
блоков в UI Kit
Запуск проекта
Обновление кода в
проектах из репозитория

25. РАДОСТЬ БЫТИЯ
Работать с фреймворком одно удовольствие – его развитие
идет легко, количество лишней работы снизилось до
минимума.

26. КАК СОЗДАВАЛСЯ
ФРЕЙМВОРК

27. 2012
НАЧАЛО
*
В середине зимы началась работа по обновлению мобильных
сайтов для современных смартфонов.
*
Мобильная версия Почты появилась в 2004 году

28. 1.
ГЛАВНАЯ
Определили общий подход – карточки
для выделения блоков с разной
информацией, общая стилистика шапки
и заголовков, элементов управления и
т.п.

29. 2.
НОВОСТИ
Решения на главной понравились –
попробовали перенести концепцию на
Новости.

30. МАСШТАБИРОВАНИЕ ДИЗАЙНА
Правда, главная – пусть и длинный, но одностраничник. А в
контент-проекте гораздо больше информации и сложнее
структура.

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

32. 3.
АФИША
Делали параллельно с главной. Масса
сервисов и достаточно сложная
структура. Интерфейсные решения
отличались от того что нам нужно для
Новостей, зато подача информации и
часть паттернов навигации пригодились.

33. ЮЗАБИЛИТИ-ТЕСТИРОВАНИЕ
Сделали много полезных выводов как для развития Афиши,
так и для представления контент-проектов на мобильных в
целом.
Например, востребованным оказалось дублирование поиска
внизу страницы. А во врезах-слайдерах последний элемент
должен вести на список всех объектов.

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

35. Дизайн-макет
Прототип

36. МАСШТАБИРОВАНИЕ ПАТТЕРНОВ
После первого же применения паттернов на новом проекте
возникло много вопросов к ним.
Например, экономить ли трафик или показывать в списках
иллюстрацию к каждому материалу? А что делать с
навигацией при разных масштабах?
*
И таких вещей – десятки
*

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

38. НАВИГАЦИЯ+ПОИСК
1.
2.
3.
4.
5.
6.
Меню разделов.
Соседние разделы.
Выход в корневой раздел.
Переход по датам.
Поиск.
Указание и выбор региона.

39. Также важно помнить, что значительная
часть пользователей заходит на контентпроекты по ссылке с главной страницы
Mail.Ru на конкретный материал, а часть
– ходит по ним с главной страницы
проекта.
Куда в этом случае должна вести кнопка
«Назад» в интерфейсе?

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

42. ГАЙДЛАЙН
Мы решили пойти дальше и собрать гайдлайн в дополнение к
нему – к задаче должны были подключиться другие
дизайнеры. Да и разработчики должны на что-то ссылаться
при сборке проекта.

43. Общая стилистика
Визуальное оформление
Сетка
Цвета и текстуры
Типографика
Иконки
Взаимодействие
Навигация
Жесты
Скроллинг
Выделение
Перетаскивание
Уведомления
Типовые элементы
Базовые компоненты экрана
Шапка страницы
Заголовок
…
Элементы управления
Уточнение поиска
Активное поле ввода
…
Навигация
Переключатель
Слайдер
…
Окна и диалоги
Попап
…
Списки
Социальный блок
…
Типовые экраны
Авторизация
…
Маркетинговые материалы
Баннеры
…

45. 4.
ГОРОСКОПЫ
Важен был еще один проект для обкатки
гайдлайна. За исключением мелких
проблем стиль работал – адаптация
прошла быстро и легко.

46. ВАЖНО:
ОБКАТКА ГАЙДЛАЙНА
Перед тем как раскидывать унификацию на десяток проектов,
нужен пилот. Он позволит обнаружить проблемы в
концепции до того, как придется переделывать слишком
многое.

47. ИДЕЯ:
ТЕХНИЧЕСКОЕ РЕШЕНИЕ
У нас уже был механизм технической унификации –
например, портальная навигация и синяя шапка. А еще
многое делается для Почты, общепортальных попапов
авторизации и других частей интерфейса. Хотя технология
требовала серьезной доработки – целые продукты на ней еще
не запускались.

50. ТРЕБОВАНИЕ:
НЕЗАВИСИМАЯ ВЕРСТКА БЛОКОВ
Разработчики ушли детально исследовать задачу и смотреть,
есть ли готовые решения и продукты. В качестве общей
идеологии отлично подходил БЭМ (блок-элементмодификатор) от Яндекса.

51. Для унификации важно, чтобы одинаковые
интерфейсные блоки использовались на как можно
большем количестве страниц. Причем без
необходимости каждый раз перепроверять, все ли
хорошо на каждой из них.
БЭМ гарантирует независимость оформления
конкретного блока от того, что происходит вокруг
него. Это методология, для упрощения работы с
которой Яндекс создал open source-инструментарий
bem-tools.
*
Кстати, наши разработчики даже отправили несколько патчей в репозиторий проекта

52. Раньше зачатки этой технологии назывались «абсолютно независимые блоки», сейчас этим
подходом проникаются на Западе – например, фреймворки http://inuitcss.com и http://topcoat.io.

53. ИНСТРУМЕНТ:
ШАБЛОНИЗАТОР
А вот шаблонизатор БЭМ оказался недостаточно
производительным, да и по задаче не очень подходил. Взяли
уже использовавшиеся у нас технологии.

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

55. ПОЛУЧИЛОСЬ:
ПРОТОТИП ФРЕЙМВОРКА
Разработчики вернулись к нам через пару недель с
прототипом – подход сработал! Фреймворк опробовали и
расширили – все было готово к масштабному развертыванию.

56. 2.5
МЕСЯЦА
12
ПРОЕКТОВ
Таких рекордов скорости мы еще не ставили. Гайдлайн
заметно вырос и описывал построение общего стиля и
многих конкретных блоков – множество навигационных
решений, списки, разные виды карточек, способы
представления контента, формы, попапы, диаграммы,
специфичные для конкретных проектов решения.

57. ОТВЕТЫ
КУРСЫ
ПОГОДА

58. ДЕТИ
ТВ
ЛЕДИ

59. HI-TECH
СПОРТ
АВТО

60. АВТОМАТИЗАЦИЯ ГАЙДЛАЙНА
Позволит отказаться от поддержки нескольких дизайнбиблиотек. Это генерируемая страница, в которую вместо
картинок подставляются реальные куски кода из фреймворка.

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

62. ПРОТОТИПИРОВАНИЕ В КОДЕ
С помощью этого автоматизированного гайдлайна можно
собирать прототипы из кусков готового кода, минуя InDesign –
это еще один способ стать ближе к конечной реализации.

63. ЛУЧШЕ, ЧЕМ BOOTSTRAP
Это набор готовых стилей и скриптов, а также примеры
верстки. И при обновлении фреймворка не так просто
перенести его изменения в свой проект – возможно, придется
подгонять верстку к новым правилам.

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

65. ПЛАНЫ НА БУДУЩЕЕ

66. ПОДДЕРЖКА РАЗНЫХ ПЛАТФОРМ
• Современные смартфоны (Android, iPhone, Windows Phone)
• Старые смартфоны (Bada, Symbian)
• Кнопочные телефоны
*
Для старых браузеров на Android показывается немного упрощенная версия – они не тянут
многие из нужных нам визуальных эффектов.
*

67. TOUCH, M, TEL

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/

74. Страна
Только через мобильные
Египет
70%
Индия
59%
ЮАР
57%
Гана
55%
Кения
54%
Таиланд
32%
Китай
30%
США
25%
Великобритания
22%
Россия
19%
конец 2010
http://www.gomonews.com/mobile-web-growth-1-in-5-internet-users-dont-use-a-computer/

75. ПОЧЕМУ НЕ ИСПОЛЬЗОВАЛИ
АДАПТИВНЫЙ ДИЗАЙН?
1. Слишком «тяжелая» по размеру версия для мобильных
при текущих технологиях.
2. Современные мобильные версии должны были появиться
как можно быстрее. Правильный адаптивный подход
требовал сначала унифицировать проекты в большом
вебе. Мы занимаемся этим, но задача сложная и долгая.

76. УНИФИЦИРОВАННЫЕ
ИКОНКИ
Мы бились над этим очень долго – во
всем мире задачу смог решить только
Яндекс и отчасти Google на Android. У
остальных все ограничивается эмблемой
в углу иконки.

77. ЯНДЕКС
GOOGLE
ZYNGA

78. АКТУАЛИЗАЦИЯ ДИЗАЙНА
Скоро нужно будет осовременить визуальный стиль – с
момента его появления пошло почти два года.

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

80. РАЗУМНЫЙ АВТОРИТАРИЗМ
Поможет не пропускать несистемных решений при
унификации.

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

82. ЧТО В ИТОГЕ?

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.