В этом кейсе мы расскажем о том, как занимались программированием нового сайта компании «Eventica».

О заказчике

«Eventica» — международное коммуникационное агентство с российскими корнями. Оно занимается организацией мероприятий высокого уровня и сопутствующими PR-активностями.

В числе их недавних заслуг — участие в организации конференции World Football Forum, выставки ЭКСПО-2015 и премии МедиаТЭК-2015.

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

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

Результат

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

Главная страница

Главная страница устроена по обычному принципу: шапка, краткая информация об агентстве, затем избранные кейсы и список новостей.

Портфолио

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

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

Но самое интересное начинается на внутренней странице кейса.

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

  • обычный текст,
  • цитата,
  • сноска,
  • изображение,
  • парное изображение,
  • слайдер,
  • цитата с фото.

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

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

Другие разделы и страницы

Остальные стандартные для корпоративного сайта разделы и страницы тоже присутствуют:

1. Новости

2. Клиенты

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

Под списком клиентов находится слайдер с отзывами.

3. Контентные страницы «О нас» и «Благотворительность».

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

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

4. Контакты

5. Поиск

Адаптивность

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

Система администрирования сайта

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

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

Админка — работа с контентом

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

Особенно удобно, что эти страницы можно видеть в админке в таком же виде, в каком они будут на сайте:

При наведении на блок показываются кнопки управления им: доступно редактирование, удаление и перемещение блока вверх или вниз по списку

Админка — приятные мелочи

На этих скринах можно можно посмотреть некоторые интересные детали интерфейса административной части сайта.

Процесс

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

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

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

На этом проекте мы решили попробовать максимально детально описать проект с трех сторон:

  • страницы,
  • элементы страниц,
  • сущности.

1. Описание страниц

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

1. Тип

  • Список объектов («С»)
  • Страница объекта («В» — «внутренняя»)
  • Контент («К»)

2. Рабочее название

3. Статус готовности

  • 0 — не сделано
  • 1 — сделано, но не залито, нужны правки
  • 2 — залито, на проверке
  • 3 — залито, проверено, на доработке
  • 4 — залито, в финальном состоянии

4. Ссылка на страницу на тестовом сервере

5. Заголовок меню

6. Title (заголовок) страницы по-умолчанию или шаблон для заголовка

7. URL

В результате получилась такая таблица

2. Описание элементов страниц

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

Каждый элемент описывался по следующим свойствам:

1. Тип источника

  • Объект
  • Список объектов
  • Контент
  • Виджет

2. Источник — конкретная сущность или справочник. (сущность это кейс, новость, вакансия, клиент и т.д.)

3. Возможность редактирования

  • да
  • нет

4. Выводимые поля объекта

5. Формат вывода

  • Для списков

    • Количество объектов
    • Фильтрация
    • Сортировка
    • Группировка
    • Формат поля (важно, например, для дат)
  • Для объектов

    • Критерий (например, «последний», «случайный», «относящийся к странице»)
    • Формат поля
  • Для виджета

    • Описание работы (если необходимо)

6. Действие по клику

Ниже снимки нескольких частей полученной таблицы

3. Описание сущностей

Аналогичный подход мы использовали и для описания полей сущностей.

Заполнялись следующие характеристики:

  1. Сущность
  2. Поле
  3. Количество
  4. Тип
  5. Обязательность
  6. Значение по-умолчанию
  7. Поле выводится в список объектов в админке
  8. Поле используется для сортировки в админке
  • да/нет
  • приоритет
  • направление (убывание или возрастание)
  1. Доступен поиск/фильтрация по этому полю
  2. Страница админке для редактирования поля
  3. Виджет для редактирования

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

Несмотря на «технический» характер используемых тут терминов «сущность», «поля», «тип поля», их стоит понимать только как «гуманитарное» описание проекта.

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

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

4. Впечатление от использования таблиц для описания проекта

Плюсы

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

Минусы

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

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

Итог эксперимента

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

5. Оптимизация изображений

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

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

С разрешением все немного сложнее, поэтому остановимся на этом подробней.

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

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

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

Зеленым цветом написаны обычные размеры, а черным — ретина.

Мы исходили из самых больших экранов — для ПК взяли за основу разрешение 1920х1080 и умножали его на коэффициент 1,5 для ретины. Для мобильных взяли 1280х720 за основу и для ретины умножали на те же 1,5 (получается 1080х1920, что и соответствует максимальному разрешению современных мобильных телефонов).

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

Хотя даже такой безусловно правильный подход встретишь нечасто, это все равно не идеальное решение. Еще лучше было бы дополнительно учитывать небольшие экраны, вроде 1366 на 768 (это обычное разрешение ноутбука 15 дюймов). Итого было бы по 6 размеров для каждого из изображений.

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

6. Коммуникации и управление задачами

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

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

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

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

Технические особенности

Проект сделан на Symfony 2.6. Задействованы известные бандлы, в том числе:

  • liip/imagine-bundle
  • vich/uploader-bundle
  • knplabs/knp-paginator-bundle
  • knplabs/knp-menu-bundle

Административная часть построена на sonata-project/admin-bundle с нашими модификациями.

Команда

Со стороны Evercode Lab в проекте участвовали:

  • Неустроев Николай — менеджмент
  • Голодяев Михаил — главный разработчик
  • Зубарев Егор — разработчик

Заключение

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