- PVSM.RU - https://www.pvsm.ru -
Обычно мы рассказываем про то, как делаем внешние продукты или их отдельные фичи — сам 2ГИС, его графику и типографику [1] или Этажи [2]. При этом тема внутренних продуктов ещё ни разу не поднималась. Исправляем эту досадную оплошность на примере «Fiji» — продукта для отрисовки интерактивной карты.
10 лет назад, когда 2ГИС был ещё маленьким, карта для него создавалась в собственной системе «ДГПП». Это был простой и понятный инструмент, как принято говорить, «соответствовавший времени выпуска [3]».
С каждым годом функций в нём становилось больше. Нужно было создавать больше объектов и делать это очень быстро. Через 10 лет «доработок» ДГПП стал таким:
В сухом остатке:
— старые технологии;
— артефакты, сакральный смысл которых затерялся в веках;
— нагромождение контролов, в котором сложно ориентироваться;
— проблемы с внедрением новых функций.
Нет предела совершенству, но дальше «улучшать» и «дорабатывать» продукт уже было нельзя. Нужно было создавать новую систему.
Сперва мы задумались об идеологии. Нужно было понять, что есть благо, а что есть зло, какие принципы будут определять то или иное решение?
Промышленная отрисовка карты — процесс нелёгкий и имеет свои тонкости:
Заказчики понимали всю сложность задачи, и о создании «интуитивно-понятного интерфейса» никто не говорил. Однако в рамках каждого конкретного этапа интерфейс должен был стать прозрачным и, насколько это возможно, подсказывать пользователю путь, по которому он должен пройти.
Создание карты — процесс дорогостоящий. Он состоит из сотен тысяч действий картографов. Если какая-то операция станет всего на пару кликов больше, в конечном итоге для компании это изменение может стоит больших денег.
Поэтому первым принципом стало «не навреди». Было бы обидно сделать красивый продукт и понять, что на выполнение элементарного действия в нём уходит больше времени, чем в продукте-предшественнике.
Помимо геометрий объектов на карте, продукт содержит большое количество сопутствующих данных.
Для постройки, например, есть назначение, адрес (улица + номер дома), материал здания, количество подъездов и этажей, высота, название и ещё десятка два различных атрибутов, которые необходимо отображать.
Это подводит нас ко второму принципу. Атрибуты и любые данные, сопутствующие отрисовке карты, должны быть видны, хорошо различимы и не теряться.
Наверняка, кто-то из вас сталкивался потерей данных, введённых на разных страницах сайта. Пишешь точный адрес, имя и фамилию, переходишь на второй экран, жмёшь сохранить… лаг… данные потёрлись, бешенство, начинаем с начала.
В нашем же случае потерянные данные — это не просто огорчение, но и трата средств компании. Система должна брать на себя работу пользователей. Использование данных по умолчанию, всевозможные автоматизации и предрасчеты — то что нам в этом поможет.
ДГПП устарел, но в нём было много хорошего. Следование процессам, отзывчивость, защита от случайных ошибок и многое другое. У пользователей сформировались привычки, некоторые из которых ускоряют работу. Для нас нас это стало третьим принципом: если в старом интерфейсе есть что-то положительное, удобное и полезное, то это нужно сохранить. Это повысит уровень лояльности пользователей и снизит их боль при переходе на новый продукт.
Во внешние продукты регулярно добавляются новые фичи, которые завязаны на контенте. Для внутренних продуктов это означает постоянное добавление требований и необходимость поддержки новых данных. Этот факт также нужно учитывать при разработке системы.
Исторически сложилось так, что enterprise-разработчики больше сфокусированы на создании новой функциональности, чем на вытачивании интерфейсов. И когда вопрос доходит до реализации, приоритет чаще отдаётся качественно сделанной логике, нежели визуальной составляющей. Поэтому приятный глазу, но простой дизайн имеет больше шансов попасть в продакшн.
Эти принципы позволили нам приходить к единому мнению в спорных вопросах и определять наиболее подходящие идеи.
О правилах договорились, пора приступить к разработке. Точнее, с декомпозиции.
Прежде всего — исследовали процесс отрисовки карты. На наше счастье технологи подробно и с любовью описали свои бизнес-процессы. Если же с чем-то разобраться не получалось, то за ответом шли в систему-предшественник или же напрямую к пользователям.
Выписали процессы и выделили в них общие действия. Например, с точки зрения действий, отрисовка дома и дороги — одинаковая. Нарисовал объект => заполнил атрибуты => сохранил. На основе такой группировки мы выделили функциональные блоки с одинаковой целью.
После того как задача декомпозирована, всё становится просто. Расставляем приоритеты и прорабатываем фичи по-отдельности.
Да, создание перекрёстка — это и есть отдельная фича. А точнее, визуализация процесса создания и редактирования перекрёстков.
Немного погрузимся в предметную область. У нас перекрёсток — это точка на пересечении звеньев дорог.
Перекрёстки несут в себе информацию о запрещённых манёврах. Например, с одной улицы нельзя повернуть на другую, либо при въезде во двор есть шлагбаум.
Прежде всего мы обратились к существующему решению.
Для ввода атрибутивной информации отрывалось окно:
Пользователь заполнял данные и нажимал «ОК». Положительный момент: данные в окне предзаполнялись.
Например, в поле «уровень» проставлялись значения уровня пристыкованных к перекрёстку звеньев. Список запрещённых манёвров подтягивался по такому же принципу. Чаще всего можно было просто нажать «сохранить». Кроме того, для запрета каждого манёвра требовался один клик, а для большей наглядности манёвр подсвечивался.
Однако в глаза бросалось, что ID звеньев в качестве опознавательного знака манёвра было не слишком информативно. Колонка «вид транспорта» (имеется в виду вид транспорта, для которого действует запрет) также не внушала доверия.
Причин две. Во-первых, несколько видов транспорта в таблице не видно. Во-вторых, для запрета движения на конкретном виде транспорта требовалось три клика для каждого манёвра. Выбор расписания запрета также занимал более трёх кликов.
После общения с заказчиками и пользователями гипотеза неинформативности ID подтвердилась. Пользователи больше смотрят на подсветку манёвра на карте, чем на ID. А вот расстановка запретов галочками считается удобной. Также мы выяснили, что расписание для манёвров вносится достаточно редко и ключевым кейсом не является.
После этого у нас родился ряд идей:
С этими мыслями в голове мы двинулись дальше.
А дальше у нас возник вопрос: пытался ли кто-нибудь решить подобную задачу? И что из этого вышло? Мы начали искать.
Изучив более 30 продуктов, мы выделили 2 паттерна, которые нам показались применимыми:
Но нам хотелось пойти немного дальше и совместить эти два подхода. Тем самым мы хотели добиться сохранения привычки и дать более наглядный и технологичный инструмент.
Следующий шаг — донести наши идеи до заказчика.
Самый простой и быстрый способ — это прямое общение.
На встречах мы рисовали скетчи идей, описывали как они должны работать и тут же получали фидбек. Было важно не просто понять, нравятся наши идеи или нет, а выяснить, что именно не устраивает, и какие практические кейсы за этим стоят.
Мы старались вытащить из заказчика максимум прикладной информации, чтобы получить единый взгляд на решение проблемы.
После нескольких диалогов концепция стала такой:
После того как все договорились, мы сделали первый вариант визуализации процесса:
Контролы для редактирования манёвров через карту, по сути, представляют собой растровые иконки, которые накладываются на перекрёсток и связанные с ним звенья.
Расстояние между иконками фиксированное и не зависит от масштаба.
При этом сохраняется возможность изменить масштаб карты.
После того, как решение показали заказчику, всплыли ещё несколько нюансов:
И мы пошли думать дальше. Новый вариант был таким:
Новая визуализация учитывала сложные случаи построения перекрёстков. А также ситуации, когда на карте много объектов одного типа находятся рядом. Кроме этого, мы проиллюстрировали варианты работы с перекрёстком на разных масштабах.
В итоге мы получили решение, которое позволяет:
Теперь, когда пользователи довольны, настала пора разработчиков. Стоит оговориться сразу, что разработчики участвовали в создании решения на всех этапах.
Каждая концепция обсуждалась с разработчиками на предмет её реализуемости. Предложенное в итоге решение было удобным для пользователя и технологичным, а функционал редактирования перекрёстков — критичным для первого релиза продукта.
Но его реализация требовала времени и оттянула бы силы команды. Требовалось найти баланс между функциональностью и удобством, поэтому мы решили подробить задачу.
Сделать редактирование манёвров через боковую панель можно было быстро. При этом выглядело оно лучше, чем аналогичное решение в старой системе. Возможность редактировать манёвры с карты выглядит удобной, но пользователи её не ждут и, следовательно, не расстроятся если в первой версии её не будет.
В суровом мире enterpise графические интерфейсы чаще отвечают на вопрос «что?» чем на вопросы «как?» и «зачем?». Повсеместно можно встретить системы, которые решают функциональную задачу, не отдавая должного внимания простоте и удобству её решения. А ведь именно удобство и следование проблематике и привычкам пользователей позволяет создавать по-настоящему полезные продукты.
Поэтому не бойтесь инвестировать время в интерфейс и поиск удобных решений. Создавайте крутые продукты, которые будут действительно экономить время пользователей, деньги компании и нервы разработчиков. Ваш труд не будет напрасным.
Автор: OlegNikishin
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/68549
Ссылки в тексте:
[1] графику и типографику: http://habrahabr.ru/company/2gis/blog/204004/
[2] Этажи: http://habrahabr.ru/company/2gis/blog/224243/
[3] соответствовавший времени выпуска: http://habrahabr.ru/company/2gis/blog/202496/
[4] Источник: http://habrahabr.ru/post/234947/
Нажмите здесь для печати.