Рисунок 11: Вид уведомления пользователя при произошедшей ошибке при регистрации

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

Рисунок 12: Главный экран приложения пользователя, ищущего помощь, после нажатия на центральную кнопку активации

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

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

Рисунок 13: Процесс подтверждения сессии со стороны волонтера

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

Рисунок 14: Возможные действия пользователя после подтверждения сессии со стороны волонтера

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

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

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

Telegram Бот. Разработка этого модуля была отставлена на поздний срок по сравнению с модулем сервера и мобильного приложения по причине его полной зависимости от двух предыдущих модулей. Технически бот зависит от базы данных и API, реализованных в составе сервера, поскольку данный инструмент работает на основе знакомой механики запросов и получает информацию из ответов сервера. Мобильное приложение является единственным интерфейсом создающегося сервиса, с которым могут взаимодействовать потенциальные пользователи. Без наличия пользователей (обеих ролей) сервис не будет являться функционирующим. Однако в случае выполнения всех условий, продукт требуется в инструменте для быстрого получения среза информации о работоспособности, количестве активных пользователях, возникающих проблемах. Именно с этой целью и создавался данный модуль.

В его основе находится стандартная реализация обработки различных команд и сценариев, происходящих при взаимодействии человека с клиентом Telegram, а точнее с конкретным ботом. Замеченная в предыдущей главе информация о открытом Bot API, именно с ним происходит постоянная работа реализованного модуля. Инициализация бота происходит по стандартной команде “/start” отправленной в диалоге с ботом.

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

В появляющемся меню, изображенном на рисунке 15, можно наблюдать следующие элементы для быстрого доступа к данным.

Рисунок 15: Основная форма Telegram Бота

На ней расположены команды для быстрой выгрузки данных из базы данных по следующим запросам (слева направо):

· Количество волонтеров, зарегистрированных в сервисе;

· Количество зарегистрированных пользователей, которые пришли в сервис с целью найти помощь;

· Текущее количество активных сессий;

· Текущее количество пользователей, которые не выбрали себе волонтера (по различным причинам).

Выбор перечисленных пунктов был сделан согласно распространенным базовым потребностям проектов на старте своего развития. При нажатии на одну из кнопок происходит кратковременная загрузка данных, а далее запрашиваемая информация появляется сверху виде текста над кнопками быстрого доступа. Ниже находится переход во вложенное меню, в котором доступны сведения о статусе работы элементов, составляющих сервер: API, называемый в данном случае «сервером» и базы данных. Переход выполняется при нажатии на элемент панели «Services». Рассмотрим вложенное меню на рисунке 16.

Рисунок 16: Форма Telegram Бота, отвечающая за статус составляющих частей сервера

Отображенные над формой данные достаточны для быстрой проверки работоспособности элементов модуля. Однако для получения более детальной информации можно обратиться либо к общему бэклогу (файлу, в который добавляются все ключевые ошибки и события, произошедшие на сервере), расположенным в виде второй кнопки снизу. Следующие кнопки позволяют за одно нажатие остановить и запустить работу обоих подмодулей. При этом сам бот не будет затронут, поскольку полностью выделен от сервера. Еще выше расположены кнопки для быстрого доступа к трем элементам: базе данных, серверу (API) и Docker контейнеру. Последний пункт создавался с целью выделенного кластера для проверки и запуска дополнительных модулей. Самая верхняя кнопка по - сути запрашивает статус работы трех основных служб, регулируемых данным инструментом, формулировку результата этого запроса видно сверху рисунка 16. Перейдем вглубь одного из подменю с элементом модуля, к примеру в сервер (API). Открывшаяся форма представлена на рисунке 17.

Рисунок 17: Форма Telegram Бота, отвечающая за статус модуля Сервер (API)

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

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

3.6 Оценка дальнейшего развития сервиса

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Заинтересованность общества и государства в создании подобных решений просматривается из различных источников. Федеральные законы, мнения людей, конкурсы инициатив. Хорошим примером в данных обстоятельствах является факт того, что первичное представление конкретно этого продукта (описанное в третьей главе работы) заняло первое место на международной олимпиаде «IT-Планета» в конкурсе «Неограниченные возможности» в 2018 году.

Список литературы

1. Techopedia.com [Электронный ресурс] / Module Definition. - URL: https://www.techopedia.com/definition/3843/module. (Дата обращения 26.02.2019).

2. Laplante P. (ed.). Dictionary of computer science, engineering and technology. - CRC Press, 2000.

3. Национальная библиотека им. Н. Э. Баумана [Электронный ресурс] / API. - URL: https://ru.bmstu.wiki/API_(Application_Programming_Interface). (Дата обращения 26.02.2019).

4. Sendpulse [Электронный ресурс] / What is RESTful API - Meaning. - URL: https://sendpulse.com/support/glossary/restful-api. (Дата обращения 26.02.2019).

5. Christensson, P. [Электронный ресурс]. Techterms. Design Pattern Definition. - URL: https://techterms.com/definition/design_pattern. (Дата обращения 26.02.2019).

6. Christensson, P. [Электронный ресурс]. Techterms. Syntax Definition. - URL: https://techterms.com/definition/syntax. (Дата обращения 26.02.2019).

7. Techopedia.com [Электронный ресурс] / Technology Services Definition. - URL: https://www.techopedia.com/definition/5569/technology-services. (Дата обращения 26.02.2019).

8. Barnett E, Casper M. A definition of "social environment". Am J Public Health. 2001;91(3):465.

9. Appinventiv development company [Электронный ресурс] / Swift vs Objective-C: 15 Ways Swift Supersedes Objective-C. - URL: https://appinventiv.com/blog/swift-vs-objective-c-15-ways-swift-supersedes-objective-c. (Дата обращения: 21.02.2019).

10. Apple [Электронный ресурс] / Apple Developer Documentation. - URL: https://developer.apple.com/documentation/. (Дата обращения: 22.04.2019).

11. Neuburg M. IOS 12 Programming Fundamentals with Swift: Swift, Xcode, and Cocoa Basics. - " O'Reilly Media, Inc.", 2018.

12. Molly K. Beginning iPhone Development with Swift 4: Exploring the IOS SDK. - " Apress ", 2017.

13. Mohamed L [Электронный ресурс] / Build RESTful API in Go and MongoDB. - URL: https://hackernoon.com/build-restful-api-in-go-and-mongodb-5e7f2ec4be94. (Дата обращения: 22.04.2019).

14. Klopfenstein L. C. et al. The rise of bots: A survey of conversational interfaces, patterns, and paradigms // Proceedings of the 2017 Conference on Designing Interactive Systems. - ACM, 2017. - С. 555-565.

15. Telegram APIs [Электронный ресурс] / Bot API. - URL: https://core.telegram.org/api. (Дата обращения: 22.04.2019)

16. Jiayu Yi [Электронный ресурс] / Introduction to the Telegram Bot API. - URL: https://chatbotslife.com/introduction-to-the-telegram-bot-api-part-1-2ae36f7b30a4. (Дата обращения: 22.04.2019)

17. Orlov B. [Электронный ресурс] / iOS Architecture Patterns. Demystifying MVC, MVP, MVVM and VIPER. - URL: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52. (Дата обращения: 21.02.2019).

18. Bart J. Mastering MVVM With Swift. - " Leanpub", 2017.

19. Microsoft patterns, Practices. Mobile Application Architecture Guide. - " Microsoft Press ", 2008.

20. Erl T. SOA Design Patterns (paperback). - Pearson Education, 2008.

21. Sйbastien P [Электронный ресурс] / Clean Architecture for a Go REST API. - URL: https://medium.com/@splisson/clean-architecture-for-a-go-rest-api-8a2aea8a5650. (Дата обращения: 22.04.2019).

22. Krishna S [Электронный ресурс] / REST API Best Practices. - URL: https://javabeat.net/rest-api-best-practices/. (Дата обращения: 22.04.2019).

23. Федеральный закон «О социальной защите инвалидов в Российской Федерации» от 24.11.1995 N 181-ФЗ (последняя редакция)

24. Правительство Москвы [Электронный ресурс] / Как получить помощь для инвалидов. - URL: https://www.mos.ru/otvet-socialnaya-podderjka/kak-poluchit-pomosch-dlya-invalidov/. (Дата обращения: 22.04.2019).

25. Кузьминов Я. И. и др. Стратегия-2020: Новая модель роста-новая социальная политика. - Издательский дом "Дело", 2013.

26. Портал Planeta.ru [Электронный ресурс] / Проект «Поможем инвалидам найти волонтеров». - URL: https://planeta.ru/campaigns/dostupotkryt. (Дата обращения: 22.04.2019).

27. Сайт общественного движения «Доступ открыт» [Электронный ресурс] / Форма для составления заявки по поиску волонтера - URL: http://dostup-otkryt.ru/ya-khochu-nayti-volontera/. (Дата обращения: 22.04.2019).

28. Сайт Московского Метрополитена [Электронный ресурс] / Заполнение заявки на сопровождение - URL: http://www.mosmetro.ru/mobile/podat-zayavku-na-soprovozhdenie/. (Дата обращения: 22.04.2019).

29. Сайт ГУП «Петербургский метрополитен» [Электронный ресурс] / Служба сопровождения граждан с инвалидностью - URL: http://www.metro.spb.ru/metroformgn.html. (Дата обращения: 22.04.2019).

30. Мобильное приложение «Мобильный центр социальных услуг» [Электронный ресурс] - URL: https://mcsumo.ru/. (Дата обращения: 22.04.2019).

31. Социальная сеть Chummy [Электронный ресурс] - URL: https://chummyapp.com/. (Дата обращения: 22.04.2019).

32. Кнопка жизни [Электронный ресурс] / Интернет магазин по продаже аксессуаров и сервиса, представляющие из себя систему мониторинга и экстренного вызова помощи - URL: https://knopka24.ru/. (Дата обращения: 22.04.2019).

33. Александр О Разработка ценностных предложений - М.: Альпина Паблишер, 2015. - 312 с.

34. Github [Электронный ресурс] / Исходный код фреймворка Alamofire - URL: https://github.com/Alamofire/Alamofire. (Дата обращения: 22.04.2019).

35. Github [Электронный ресурс] / Исходный код визуальной библиотеки SCLAlertView-Swift - URL: https://github.com/vikmeup/SCLAlertView-Swift. (Дата обращения: 22.04.2019).

Размещено на Allbest.ru