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

1. Производителя (в нашем случае, это японская компания Janome, мировой лидер по производству швейной техники с экспортом в более чем 100 стран мира);
   
2. Самого дистрибьютора (компании «ЭЛФОРТ», которая является официальным поставщиком продукции Janome на русскоязычный рынок);
   
3. Дилеров (а это уже, на секундочку, тысячи магазинов в России, Беларуси, Казахстане и Узбекистане, которые приобретают технику Janome у компании «ЭЛФОРТ»);
   
4. Конечных потребителей (речь о тех миллионах человек, от новичков до профессионалов, которые приходят в эти магазины, чтобы купить одно из решений Janome).

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

Если на сайте представлены абсолютно все возможные модели — это счастье для производителя и разочарование для конечного потребителя. Любой пользователь хочет видеть только те товары, которые ему подходят. А этим пользователем на сайте Janome может быть как человек со скромным бюджетом и нулевым швейным бэкграундом, так и виртуоз вышивки, который готов побаловать себя машинкой за 400 тысяч рублей.

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

На сайте представлены сотни специализированных и интернет-магазинов, торговых сетей, сервисных центров. Для каждого из них нужен был собственный URL. Проблема в том, что один из паттернов поведения пользователя на сайте — переход от магазина к магазину. А собственный URL для каждого дилера требует, чтобы при клике на новый магазин, страница обновлялась. Это было бы неудобно для пользователя.

History API, JS контроллер

Решением стал History API. Когда мы нажимаем на какой-нибудь магазин, в адресной строке меняется URL и в историю просмотров добавляется еще один пункт, как будто мы перешли на другую страницу. Но, на самом деле, страница не обновляется — просто на ней меняется часть содержимого. Технически это означает, что браузер использует ресурсы, которые получил при первой загрузке страницы, а далее при каждом переходе по сайту он перезагружает только необходимый контент. Теперь перестроение URL’а без обновления страницы нужно было увязать с картой и навигацией. Для этого мы написали js-ный контроллер для клиентского кода.

Детект

Определение местоположения для магазина срабатывает независимо от выбора местоположения в шапке. Когда пользователь в первый раз заходит на сайт, автоматически определяется его местоположение. Соответственно, если он зайдет на страницу «Специализированные магазины», ему будут показаны магазины в его городе — на карте и в списке. Но если он перейдет потом на другую страницу, например, «Торговые сети» и выберет вручную там Беларусь, то сайт запомнит, что его интересует Беларусь и, когда он вернется в «Специализированные магазины», покажет ему уже магазины в Беларуси. При этом местоположение в шапке не поменяется. На карте же будут абсолютно все магазины Беларуси, а ниже — пагинация, навигационный ссылочный блок, который разбивает весь этот массив данных на отдельные веб-страницы. Таким образом, сайт учитывает переходы пользователя от вкладки к вкладке. В соответствии с этим меняется карта, меняется блок навигации и url. Неважно, кликнул пользователь по магазину на карте или в списке.

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

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

Вообще, в техническом плане, это одна из самых интересных страниц, потому что содержит больше всего js кода по сравнению с остальными, за исключением, возможно, главной. И это не только из-за функционала «Поделиться». Здесь нужен был и нестандартный слайдер, который бы поджимался на адаптиве. И чтобы у таблицы была плавающая шапка. И чтобы можно было в один клик переключать сравнение товаров со «Всех характеристик» на «Различия» и обратно, и при этом не нарушалась чересстрочная отрисовка по цветам. И чтобы расчет высоты строки каждый раз запускался при ресайзе окна. И Drag and Drop был шустрым. В общем, разработчикам пришлось повозиться.

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

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

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

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

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

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