Как мы искали готовую UI-библиотеку, но в итоге создали её сами

Разработка простых интерфейсов для сложных систем

В конце 2017 года у нас в Everpoint сложилась следующая ситуация: есть большой опыт реализации самых разнообразных геоинформационных проектов, есть набор технологических решений для эффективной работы с геоданными, который в различных вариациях используется в back-end разработке на таких проектах, а универсальных интерфейсных решений нет. В итоге каждый проект требовал огромного объема однотипных работ по проектированию и разработке интерфейса. То же самое касалось и нашего основного продукта — геоинформационной платформы EverGIS. Каждое усовершенствование, внедрение новой фичи или кастомизация в интересах внешнего заказчика сулили проектирование новых интерфейсов практически с нуля. Кроме того, накопившиеся доработки и разнородные модули в приложении сделали затруднительной его дальнейшее развитие.

В геоинформационных системах (ГИС) важно использовать в интерфейсе привычные, хорошо продуманные элементы, но при этом позволяющие полноценно работать с их богатым функционалом. Это особенно актуально для геосервисов, ориентированных на широкий круг пользователей (журналистов, экономистов, маркетологов, предпринимателей, студентов и т.д.), а не только на профессиональных картографов и геоаналитиков. О влиянии современных трендов UX-дизайна на картографические сервисы подробнее тут.

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

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

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

Cамое очевидное решение с точки зрения экономии ресурсов — воспользоваться уже существующими библиотеками (material-ui, antdesign и другие). Не для всех из них есть доступные графические библиотеки, но наличие дизайн-гайдов в большинстве случаев компенсирует эту проблему. Но когда мы попытались подобрать подходящую библиотеку, обнаружилось следующее:

Оказалось, что нет ни одной UI-библиотеки, ориентированной на создание ГИС. Что ж, придется сделать ее самим.

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

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

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

Исходя из принципов атомарного дизайна, мы начали разработку библиотеки с элементарных вещей — общих принципов дизайн-языка (тут мы даже претендуем на дизайн-систему), цветовых схем, cхем анимации, типографики, простейших управляющих компонентов. Предполагалось, что как только будет накоплен достаточный объем готовых компонентов, они будут внедряться в уже существующее приложение, заменяя старые. Однако, внедрение оказалось довольно трудоемким. Кроме того, началась разработка нового публичного геосервиса — EverGIS Online c новым интерфейсом — и мы решили сосредоточиться на применении новой библиотеки именно к нему. От первоначального плана библиотеке достались широкие возможности настройки и кастомизации.

Спустя год после начала работы (помимо описанных на начальном этапе правил дизайна) у нас есть: библиотека компонентов в Storybook, состоящая более чем из 50 компонентов разного уровня, подробные описания и примеры использования для каждого компонента и библиотека в Sketch — то есть почти все составляющие дизайн-системы. Работы над библиотекой еще не закончены, она растет и развивается.

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

Кроме визуальных результатов в виде библиотеки и приложения мы получили приятные бонусы для рабочего процесса в целом. Создание UI-библиотеки положительно повлияло на производительность проектирования и разработки:

#Everpoint #геомаркетинг #ux #картография #ГИС #веб_дизайн