На карте всё есть, но найти ничего нельзя: 6 ошибок при разработке интерактивных карт

Фильтр «Открыто сейчас» показывает закрытый аттракцион, а маршрут ведёт к запертым воротам. Разбираем шесть ошибок, которые стоит исправить ещё до запуска карты.

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

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

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

Кластеризация описана в рекомендациях Google Maps Platform, но применять её можно и с другими картографическими технологиями.

В одном из туристических проектов DIGITAL SECTOR объекты на карте были связаны с фильтрами и тематическими подборками. Посетитель мог выбирать интересующие места, а не разбираться во всём каталоге одновременно.

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

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

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

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

Причина — интерфейс начали проектировать раньше, чем определили структуру и источники данных.

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

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

Если описание находится в CMS, а доступность билетов определяется внешним сервисом, не стоит создавать вторую независимую базу, которую сотрудники будут обновлять вручную. Лучше связать системы и определить правила обмена.

В одном из туристических проектов DIGITAL SECTOR на карте отображались категории объектов с отдельными иконками, график и режим работы. Завершившиеся события переставали отображаться. Такие сценарии возможны только тогда, когда даты, статусы и категории существуют как данные, с которыми система умеет работать.

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

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

Выбрать категорию можно. Указать возраст — тоже. Отфильтровать работающие объекты — отдельно. А вот применить эти условия вместе не получается. Или фильтры работают, но после открытия карточки сбрасываются, и поиск приходится начинать заново.

Проблема касается не только поиска. Например, пользователь нашёл подходящую экскурсию, но в карточке нет даты, стоимости или перехода к покупке билета. С точки зрения разработчика карта работает. С точки зрения посетителя задача не решена.

Чтобы этого избежать, ещё до проектирования интерфейса стоит описать несколько основных сценариев:

Сценарий 1. Посетитель хочет найти работающий аттракцион для ребёнка определённого возраста.

Сценарий 2. Гость курорта ищет ближайший ресторан, смотрит часы работы и переходит к бронированию столика.

Сценарий 3. Турист выбирает несколько достопримечательностей и сохраняет их для прогулки.

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

Важный момент — поведение интерфейса при отсутствии результатов. Пустая карта без объяснения заставляет пользователя гадать: объектов действительно нет или что-то сломалось? Лучше показать понятное сообщение и предложить изменить условия поиска.

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

Готовый маршрут — заранее подготовленная прогулка с фиксированными остановками. Для него можно сохранить последовательность мест и линию пути.

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

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

Пошаговая навигация — сопровождение человека во время движения с определением его местоположения и подсказками, куда идти дальше.

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

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

Показательный пример — мобильное приложение Grená Park, разработанное DIGITAL SECTOR.

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

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

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

Иногда дело заканчивается тем, что для исправления координат или удаления маркера приходится писать разработчику.

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

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

Для сложных проектов полезна схема «черновик → проверка → публикация». Пока изменения проходят согласование, посетитель должен видеть последнюю опубликованную версию карточки.

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

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

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

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

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

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

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

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

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

В проекте Grená Park DIGITAL SECTOR также отдельно работал над быстродействием и тестировал приложение на устройствах с iOS и Android.

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

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

Разработка интерактивной карты начинается с восьми вопросов, на которые стоит ответить до оценки проекта:

Эти ответы можно использовать как основу требований. Если нужна более подробная структура, в статье DIGITAL SECTOR «ТЗ для разработчиков: как описать будущую систему до начала разработки» разобрано, как перейти от бизнес-задачи к функциям и критериям приёмки.

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

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