Кому нужен лендинг как у Apple, и как его сделать?

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

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

Так бы это все и осталось в планах, но тут звезды сошлись. Сначала мы придумали набор для Амперки, который нравится самим. Это идеальный продукт для такого сайта. Я в отдельной статье написал, как мы его делали. А потом наступил карантин, текущие проекты затормозились, запуск новых отложился на неопределенный срок. Появилась свободная команда. Мы поработали два месяца и сделали промо-сайт Cyber Bug.

Или кому нужен лендинг как у Apple, если ты не Apple? Мы начали этот проект для себя, чтобы отработать технологии. В процессе работы я подумал, какому бизнесу это может быть нужно.

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

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

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

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

Мы сделали черновую модель и анимации в Cinema 4D и потом собрали в After Effects прототип сайта. AE — это программа для видеоэффектов, собирать там сайт непривычно, зато получается не унылый прототип, а классная видео-история.

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

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

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

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

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

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

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

На работу с этим проектом мы потратили месяц плотной работы команды из трех человек, это 480 человеко-часов. Неплохо для своего проекта.

Концепция: Артем Петрович

3Д и анимация: Арсений Петрович

Программирование: Евгений Зозуля