В качестве дополнительной задачи для повышения удобства использования можно разработать веб-интерфейс.

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

2 Определение функционала и используемых технологий

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

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

– авторизация;

– подача заявки;

– отслеживание статуса исполнения работ.

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

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

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

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

– авторизация с разделением ролей;

– получение детальной информации о конкретном заказе;

– детализированное отслеживание и редактирование статуса заказа;

– просмотр заказов в работе;

– доступ к документации и технической информации по заказу.

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

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

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

Таким образом о пользователях приложения (как со стороны клиентов, так и со стороны сотрудников) требуется хранить следующую информацию:

– логин;

– пароль;

– электронный адрес;

– фамилия, имя, отчество.

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

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

– полное название организации;

– юридический адрес;

– почтовый адрес;

– ИНН;

– КПП;

– ОГРН.

О заказах требуется хранить следующий перечень информации:

– начальную точку маршрута;

– конечную точку маршрута;

– статус выполнения;

– массу груза;

– геометрические характеристики груза;

– перечень затребованных дополнительных услуг;

– особые характеристики груза [8].

Структура базы данных приложения представлена на рисунке 3.

Рисунок 3 – Структура базы данных приложения

В качестве СУБД выбрана MySQL – свободно распространяемая система управления базами данных. MySQL реализует реляционных подход, проста в использовании, быстра и надежна. На данный момент является одной из самых популярных СУБД для реляционных баз данных, обмен данными с базами данных под управлением MySQL удобно организован во многих языках программирования. Все вышеперечисленное делает MySQL приемлемым выбором для управления базой данных [9].

Так как база данных и приложение не могут взаимодействовать напрямую им требуется промежуточный формат передачи данных. В качестве такого формата выбран JSON – легкий, открытый, формат обмена данными. JSON, появившийся как формат описания объектов в JavaScript, теперь является текстовым форматом, удобным для использования человеком и применяется во многих языках программирования из-за удобства его синтаксического анализа [10].

В качестве языка для реализации серверной части приложения язык сценариев общего назначения PHP, который широко используется в веб-разработке, прост в использовании, легко организует работу с базами данных и удобен для преобразования данных в формат JSON [11].

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

По данным на второй квартал 2015 года, 82,8% рынка смартфонов составляют Android-устройства, а суммарная доля Android на рынке смартфонов и планшетов составляет 53,54%. В период с ноября 2014 года по сентябрь 2015 Android показал прирост своей доли на рынке на 7,76%, что делает его самой популярной мобильной платформой. Такая ситуация на рынке объясняется широким спектром устройств, работающих под Android, и гибкой ценовой политикой [12, 13]. Учитывая статистику, можно заключить, что вероятность того, что клиент или сотрудник будет использовать для постоянного использования смартфон или планшет под управлением Android высока. Помимо этого, разработка под Android не требует никаких дополнительных стартовых вложений, кроме внесения разового платежа в размере 25 долларов США, для регистрации разработчика для последующего размещения приложения в Google Play, официальная интегрированная среда разработки Android Studio поставляется Google бесплатно.

3 Проектирование приложения

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

Помимо общих рекомендаций и принципов разработки пользовательских интерфейсов Google предлагает ряд своих:

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

– возможность прямого взаимодействия с объектами предпочтительна простым меню и кнопкам;

– возможность персональной настройки некоторых параметров интерфейса приложения сказывается положительно на мнении пользователя о нем;

– приложению следует изучать предпочтения пользователя для автоматической перестройки интерфейса для быстрого доступа к часто используемых функциям;

– подсказки, оповещения и прочая текстовая информация должна быть лаконична;

– приветствуется использование графики и изображений;

– не следует перегружать пользователя выполнением монотонных функций: приложению следует принять решение за него в некоторых ситуациях, но пользователь должен иметь возможность отмены и изменения конечного решения;

– на экране следует отображать только самое необходимое;

– пользователь всегда должен быть в состоянии определить в каком месте приложения находится;

– особенно тщательно следует хранить данные пользователя (запоминать личные настройки и т.д.);

– внешне похожие элементы должны вести себя одинаково и предсказуемо;

– прерывать пользователя стоит только в важных ситуациях;

– пользователю следует предоставлять привычные для него приемы управления;

– следует быть корректным с пользователем, предоставляя четкие рекомендации по устранению проблем;

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

– наиболее приоритетные функции должны находится в быстром доступе и так же быстро выполняться [14].

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

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

Рисунок 4 – Активные зоны экрана при удержании: а) одной рукой, б) двумя руками

вертикально, в) двумя руками горизонтально

Проектирование приложения начинаем с составления макетов основных экранов приложения согласно выполняемым ими функциям.

В качестве языка описания ресурсов различного типа (макеты, строки, цвета, стили и т.д.) в Android используется XML – ответвление SGML, стандартного обобщенного языка разметки, простой в созданий и удобный в использовании инструмент для описания данных, в частности, создания иерархии элементов экрана и присвоения им требуемых свойств.

Первым экраном приложения является экран авторизации пользователя, представляющего собой простой макет LinearLayout (Vertical), имеющий в качестве потомков набор из полей EditText и виджетов TextView и Button, достаточных для авторизации или для перенаправления на экран регистрации (рисунок 5).

Рисунок 5 – Экран авторизации пользователя

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

Рисунок 6 – Экран регистрации: а) пользователя; б) компании