Редизайн убрал сайдбар, а вместе с ним единственный способ починить сломанную страницу

Визуальный редактор сайта в inSales — то место, где владельцы магазинов меняют дизайн и управляют виджетами. inSales — e-commerce-платформа с 60 000+ магазинов, и этот редактор один из её основных инструментов. Страница магазина открывается в iframe внутри админки, а редактор позволяет работать с виджетами на этой странице.

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

Редизайн, который мне передали, это исправлял. Общие настройки и навигация по страницам ушли в верхнее меню. Действия с виджетом переехали в предпросмотр: выбираешь виджет, нажимаешь «Редактировать», и поверх витрины открывается плавающая панель с его настройками. Постоянного сайдбара больше не было. Я получил макеты и примерно восемь недель реализовывал frontend.

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

Что тихо делал сайдбар

Владельцы магазинов и их разработчики могут добавлять в виджеты собственный HTML, CSS, JavaScript и Liquid. Критическая ошибка в таком коде может сделать так, что страница магазина перестанет загружаться или вернёт серверную ошибку.

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

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

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

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

Технический режим

Я предложил технический режим, который работает без iframe, и сделал его.

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

/** Сообщает о сломанном предпросмотре, если на странице так и не появилось ожидаемое содержимое. */
function watchPreview({ iframe, timeout, onBroken }) {
  const timer = setTimeout(onBroken, timeout)

  iframe.addEventListener('load', () => {
    clearTimeout(timer)
    if (!hasExpectedContent(iframe.contentDocument)) onBroken()
  }, { once: true })
}

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

Важнее кода тут были два решения.

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

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

Та же дыра, только тише

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

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

Что вышло в продакшен

Новый редактор стал стандартной версией для шаблонов последнего поколения и используется более чем в 90% магазинов inSales. Старый редактор с постоянным сайдбаром остался только для шаблонов, созданных до 2020 года, на нём несколько сотен пользователей.

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

Цифры ниже относятся к редизайну целиком, а не только к техническому режиму:

• При закрытых верхнем меню и панели настроек предпросмотр на экране 1920 px стал шире примерно на 17%: сайдбар больше не отнимает у него постоянную полосу.
• Среди новых пользователей доля тех, кто в первой сессии сам изменил настройку шаблона или виджета и успешно сохранил результат, выросла с 60% до 80%. Это плюс 20 процентных пунктов, то есть разница между двумя долями: было трое из пяти новых пользователей, стало четверо из пяти.

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

Прежде чем удалять панель

Теперь, когда редизайн убирает или объединяет часть интерфейса, я прохожу по такому списку:

• Выписать все задачи, которые решает старый элемент, включая те, что никто не рисовал: состояния ошибки, пустые состояния, элементы, которые не видны до определённого действия, сценарии поддержки.
• Для каждой задачи найти её место в новом дизайне. Если ответ «нигде», сказать об этом вслух до релиза, а не ждать, пока это обнаружит поддержка.
• Посмотреть на новый дизайн в состоянии, когда его главная поверхность не работает. Если кнопки живут внутри того, что редактируется, что будет, когда это не отрисуется?
• Оставить аварийный выход доступным в обычной работе, чтобы о нём знали заранее.

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

Подробнее о проекте — в кейсе о визуальном редакторе.