Розробка мобільного застосунку для віртуальної виставки

Віртуальна виставка: застосунок втрачає відвідувачів на вході

Відвідувач відкриває застосунок віртуальної виставки саме в той момент, коли стартує експозиція.

Перший екран має з'явитися за пару секунд, а замість цього крутиться заставка: каталог стендів, розклад і картки експонентів тягнуться із сервера єдиним блоком, поки вантажиться все — від обкладинок до списку доповідей.

Відтік відвідувачів на вході тут найдорожчий із можливих: той, хто не додивився заставку, не дійде до жодного стенда й не залишить жодного контакту.

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

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

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

Рішення, розраховане на середній потік, ламається саме в ці хвилини, і платить за простій не майданчик, а експонент, який чекав на відвідувачів біля свого стенда.

Розбираємо, як це закривається: де в застосунку для виставки ставляться межі відмови, що підвантажується заздалегідь і як вхід перестає залежати від піку.

Навігація стендами, розклад і збір контактів

Перший екран вирішує, чи дійде відвідувач до експонента взагалі. Карту виставкової зали ми виносимо нагору й будуємо на базі Mapbox: векторний шар із пошуком за номером стенда, маршрут від входу, позначка «я тут».

Схему кешуємо під час першого запуску — навігація стендами працює в залі, де мережа перевантажена або зникає. Час до першого стенда падає з хвилин блукання за вказівниками до 30–60 секунд.

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

Збір контактів відвідувачів закривається одним дотиком: код на стенді, підтвердження згоди, обмін візитівками в обидва боки.

Записи лягають у локальне сховище й вирушають до корпоративної бази контактів пакетами за появи мережі — експонент отримує список із позначкою, де й коли відбулася розмова, а не стос папірців.

Пік входів — головний ризик: зала відкрилася, сотні людей одночасно відкривають карту й розклад. Гарячі дані віддаємо з кешу, а позначки й заявки складаємо в чергу та надсилаємо в міру вивільнення каналу. Застосунок залишається чуйним, і частка тих, хто дійшов до експонента, не просідає в перші хвилини.

Режими роботи: офлайн-карта, гібрид, веб-версія

Вибір між офлайн-картою, гібридним режимом і веб-версією — не смаковий. Він визначається майданчиком, стійкістю зв'язку й тим, як часто змінюється програма в дні події.

У павільйоні з товстими стінами й перевантаженою точкою доступу мережа відвалюється саме в годину пік, а на відкритому міському майданчику відвідувач швидше відкриє посилання, ніж встановить застосунок.

Картографічну підкладку для автономного шару збираємо з відкритих даних OpenStreetMap і нарізаємо на фрагменти заздалегідь — застосунок не звертається до мережі за картою й працює в авіарежимі.

Далі залишається вибрати з трьох варіантів, і в кожного є своя ціна в підтримці та сценарії, які він не закриває.

На практиці частіше виграє гібрид, але тільки якщо заздалегідь призначено джерело правди для розкладу й схеми залів. Без цього автономний шар і сервер розходяться, і відвідувач бачить скасований захід на своєму екрані.

Етапи впровадження: від аудиту експозиції до передачі

Роботи йдуть хвилями, і кожна закінчується артефактом, який можна перевірити до старту наступної. Порядок не випадковий: поки не ясно, що саме показує експозиція й як часто це змінюється, застосунок перетворюється на набір статичних екранів, які до відкриття вже застаріли.

1. Аудит виставкового контенту. Інвентаризація стендів, медіа, розкладу, карт залів і зв'язків із системою реєстрації. Результат — карта розділів і таблиця джерел даних із частотою оновлення.
2. Схема й прототип потоків. Визначаємо, що оновлюється через адмінку без перезбірки, що кешується на пристрої, як поводиться екран за обриву зв'язку в павільйоні. Результат — узгоджена архітектура й клікабельний прототип ключових сценаріїв.
3. Збірка ядра. Навігація залами, розклад, сповіщення, вхід за квитком або запрошенням, аналітика відвідувань. Результат — робоча збірка на тестовому контурі, а не макет.
4. Навантажувальна перевірка застосунку. Прогін на сценарії одночасного входу відвідувачів у момент відкриття, перевірка деградації за слабкої мережі та поведінки за недоступного сервісу. Результат — звіт із вузькими місцями й виправленнями до публічного запуску.
5. Пілот на реальному трафіку. Закритий прогін на групі відвідувачів: дивимося час до першого екрана, частку успішних входів і кількість збоїв. Результат — правки за фактом поведінки, а не за припущеннями.
6. Впровадження застосунку виставки. Публікація в магазинах застосунків, проходження перевірок, підготовка чергування інженерів на дні заходу.
7. Передача проєкту замовнику. Репозиторій, доступи, регламент оновлення контенту та інструкція з випуску нової версії силами вашої команди — без нашої постійної підтримки.

Критерій приймання кожного етапу фіксуємо заздалегідь: етап не вважається закритим, поки артефакт не прийнято. Це прибирає ситуацію, коли до відкриття з'ясовується, що розклад у застосунку не збігається з майданчиком.

Конфігурації, схеми й регламенти на виході

Комплект передачі — це не архів із вихідним кодом, а набір документів і налаштувань, за яким стороння команда розгортає стенд, випускає оновлення й змінює контент без нас.

Ми збираємо його паралельно з розробкою: якщо схема інтеграцій відновлюється лише з пам'яті інженера, проєкт не вважається зданим.

• Конфігурації середовищ. Адреси сервісів, ключі доступу й параметри збірки винесені з коду в окремі файли — тестовий і промисловий контур перемикаються зміною конфігурації, а не правкою вихідників.
• Схема інтеграцій виставки. Напрямок і формат обміну із системою реєстрації та продажу квитків, зовнішньою CRM, плеєром трансляцій і аналітикою; окремо — поведінка за недоступності кожного сервісу.
• Права доступу до даних відвідувачів. Матриця ролей: організатор бачить агреговану статистику, стендист — лише своїх гостей, вивантаження персональних даних — окрема роль із журналом операцій і терміном зберігання.
• Регламент оновлення контенту. Що змінюється через адмін-панель без випуску нової версії застосунку (розклад, стенди, відео, презентації), а що потребує перезбірки й перевірки на тестовому контурі.
• Документація щодо застосунку. Опис архітектури й сховища, специфікація внутрішнього програмного інтерфейсу, інструкції зі збірки, підпису та публікації в магазинах застосунків.
• Регламент випуску та відкат. Порядок роботи з гілками, обов'язкові перевірки на критичних шляхах, приймання й повернення до попередньої стабільної збірки.
• Передача проєкту й підтримка. Володіння акаунтами розробника й сервісів переоформлюється на замовника, фіксується гарантійне вікно й умови подальшого супроводу.

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

Кейс: експозиція на кілька залів і пікові входи

Що було на вході

Оператор виставкового майданчика Експофорум прийшов із класичним болем: відвідувач завантажував застосунок заздалегідь, а на місці губився між залами.

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

Заміри минулого заходу дали базу для порівняння: доходимість — 52%, звернення до підтримки — близько сотні за день, переважно «де я і як пройти».

Що змінили

Перезібрали шлях відвідувача: вхід за кодом прямо з екрана блокування, карта з прив'язкою до маяків у залах, маршрут будується від поточної точки до вибраного стенда.

Стенд позначається одним дотиком — позначка одразу йде до статистики організатора, а відвідувачу показуються сусідні експозиції за темою.

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

Що стало

Час від входу до першого стенда скоротився вдвічі, доходимість зросла з 52% до 79% — майже кожен, хто відкрив карту, дійшов до експонента. Звернення до підтримки впали приблизно в п'ять разів, частка питань про навігацію — з більшості до поодиноких.

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

Що робити, якщо застосунок уже випущено, а експозиція змінюється

Якщо застосунок уже встановлено у відвідувачів, а експозиція змінюється, перевипуск збірки — найгірший із доступних шляхів. Магазини перевіряють реліз, частина гостей оновиться через тижні, частина не оновиться взагалі, і на майданчику поряд опиняться люди з різними версіями. Для виставки, яка живе кілька днів, це означає роз'їхатися навігацію та втрачені стенди.

Робоче рішення — винести опис експозиції зі збірки на сервер. Застосунок під час запуску запитує конфігурацію: список залів, схему проходів, точки інтересу, розклад сесій і прив'язку контенту до стендів.

Поки модель даних описана версійно й клієнт уміє читати як поточну, так і попередню схему, додавання зали або перенесення часу доповіді не потребують нової збірки.

Окрема задача — міграція на нову структуру залів, коли майданчик змінює планування. Старим ідентифікаторам зіставляються нові, навігація отримує правила переходу, а вибране, маршрут і прогрес за квестами переносяться на актуальні точки.

Гість не помічає зміни схеми: він відкриває застосунок і бачить той самий маршрут, просто новими залами.

Оновлення експозиції без перевипуску спирається на управління контентом виставки: організатор сам править стенди, спікерів і таймінг, а правила кешування визначають, коли клієнт забирає свіжі дані, а коли працює зі збереженою копією — на майданчику зв'язок часто нестабільний.

Доопрацювання наявного застосунку потрібне, лише якщо з'являється новий тип контенту або нативний модуль: тоді реліз неминучий, але викочується поступово, з флагами й моніторингом падінь.

Розбір починається з аудиту поточної збірки: що вже параметризовано, а що вшите в код. Далі плануємо зміни так, щоб встановлені версії продовжували працювати.

Обмеження: слабкий зв'язок, старі пристрої, офлайн

Павільйони з бетонними стінами й перевантаженим ефіром — звична справа: гість підходить до стенда, а мережа не віддає навіть сторінку.

Тому логіка будується від офлайн-сценарію: каталог учасників, карта й матеріали стендів лежать у локальному сховищі, а дії відвідувача встають у чергу й вирушають на сервер, щойно канал повернувся. Гість не помічає підміни, реєстрації та контакти не губляться за обриву.

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

Важкі тривимірні сцени на слабкому залізі підміняються статичними панорамами — застосунок не падає, а підлаштовує подачу під можливості апарата.

Дані відвідувачів збираємо щонайменше — лише потрібне для реєстрації та передачі контакту учаснику. Токени доступу лежать у захищеному сховищі системи, передача йде шифрованим каналом, на пристрої залишається знеособлений кеш.

Застосунок працюватиме на пристроях, яким кілька років?

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

Як захищені дані відвідувачів?

Збираємо мінімум полів, шифруємо передачу, розмежовуємо доступ співробітників за ролями. На запит замовника дані видаляються разом із виставкою.

Обговоримо задачу: зберемо план і оцінку за вашою експозицією

Щоб оцінка термінів розробки спиралася на факти, а не на здогадки, нам потрібен мінімум вхідних даних — зазвичай достатньо однієї розмови й доступу до матеріалів. Нижче список того, що прискорює розрахунок найбільше.

• Карта експозиції: план залів і стендів, точки інтересу, логіка переходів між ними — у векторах, таблиці або навіть начерку від руки.
• Контент: описи експонентів, медіа, посилання на трансляції, вимоги до мов і розкладу подій.
• Сценарій відвідувача: як людина потрапляє до застосунку, що вважаємо цільовою дією — перегляд стенда, заявка, особиста зустріч.
• Інтеграції: система реєстрації, каталог учасників, облік заявок — із доступом до тестового контуру й прикладами відповідей.
• Платформи й умови: пріоритетні пристрої, чи потрібен офлайн-режим для павільйонів зі слабким сигналом, вимоги до входу.
• Доступи й погодження: облікові записи для збірки та публікації, хто затверджує макети, правила роботи з персональними даними.
• Обмеження: дата відкриття виставки й події програми, які не можна зсунути.

На цій підставі ми повертаємося з планом робіт щодо застосунку виставки: етапи, їхня тривалість, склад команди та точки приймання на кожному кроці.

Якщо план підходить, обговорюємо розробку застосунку й запускаємо старт проєкту виставки — опишіть задачу, і ми повернемося з оцінкою та запропонованим порядком дій.