BMC на разных экранах: как мы делали адаптив без готовых макетов

Привет, Хабр! Меня зовут Настя, я фронтенд-разработчик в OpenYard и занимаюсь веб-интерфейсом BMC (Baseboard Management Controller) — системы, через которую можно управлять сервером и следить за его состоянием.

До OpenYard я несколько лет работала в веб-разработке: делала сайты и большие веб-приложения, участвовала в проектах для Госуслуг, Grom.place, сети ломбардов и других компаний. Сам фронтенд после перехода в серверную разработку был мне знаком, а вот предметная область — нет: веб-интерфейс здесь часть прошивки и работает с BMC по Redfish.

Постепенно к терминологии я привыкла и стала лучше понимать, как устроена сама разработка. Я напрямую работаю с BMC-разработчиками: для моего фронтенда это бэкенд-команда. Они реализуют серверную часть задачи, после чего новые поля и операции нужно вывести в веб-интерфейс. Основной API здесь — Redfish. С BIOS-разработчиками я пересекаюсь реже, хотя часть данных из BIOS тоже в итоге попадает в BMC.

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

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

Интерфейс, который рассчитывали только на десктоп

В веб-разработке есть два классических подхода: mobile first и desktop first. В первом случае интерфейс сначала проектируют для маленького экрана и затем расширяют, во втором идут от десктопа к меньшим разрешениям. Но в обоих случаях понятно, что интерфейс будет работать на разных экранах, и это учитывается еще на старте.

Наш BMC исторически создавался иначе — так, будто всегда будет открываться только на большом экране. Сетки страниц под узкое окно не проектировали.

Первые проблемы появились даже не на смартфонах, а на обычных компьютерах, если BMC открывать не на весь экран.

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

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

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

Почему промежуточная версия оказалась самой сложной

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

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

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

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

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

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

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

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

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

Адаптив помог найти старые баги

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

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

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

Зачем вообще BMC на телефоне

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

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

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

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

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

Темная тема и разные версии одного BMC

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

На словах все просто: белое сделать темным, темное — светлым. В реальности интерфейс сложнее.

Возьмем обычную иконку. В светлой теме это темный рисунок на светлой кнопке. В темной иконку уже нужно сделать светлой. При наведении появляется еще одно состояние. Плюс есть active- и disabled-состояния.

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

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

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

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

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

Как интерфейс BMC развивается дальше

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

Например, недавно мы обратили внимание на реализацию выбора часового пояса через карту мира. В BMC есть несколько способов получить время: взять из BIOS, задать вручную или использовать NTP-сервер. В другом решении мы увидели вариант с картой, где пользователь выбирает регион, а интерфейс выставляет правильное смещение.

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

В итоге я нашла подходящую основу, убрала лишние элементы, переделала цвета, расставила точки регионов и адаптировала карту под наш BMC.

Мне нравятся задачи, в которых фронтенд выходит за рамки работы по готовому макету. Где-то нужно самой продумать поведение интерфейса, где-то — разобраться с BMC или Redfish, а где-то пригодятся вещи, которые я когда-то изучала в университете.

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

Основная проблема здесь — вес. Исходная модель может занимать около 100 МБ, а для веб-интерфейса нам нужно уложиться примерно в 2 МБ. Поэтому приходится работать с геометрией, материалами, сглаживанием и оптимизацией.

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

Но это тема для отдельной статьи. Как и ещё один случай, где пришлось выйти довольно далеко за пределы привычного фронтенда. Через виртуальный носитель серверу можно отдать файл-образ, но не папку. Папку браузер сначала собирает в FAT32-образ, и уже этот образ уходит на BMC по WebSocket — тем же путём, что и обычный ISO. Если будет интересно, в следующий раз расскажу, почему готового решения для этой задачи не нашлось.