Экран Add. 
Проектирование программного пользовательского интерфейса и алгоритмов работы для электронного сервиса напоминаний для мобильных устройств

Рисунок 17 Экран ADD.

Экран в котором находятся все настройки метки. Экран состоит из кнопки возвращения на предыдущий экран, при этом метка не сохраняется. Триггера in/out (положение in включает оповещение при вхождение в область метки, режим out при выходе из нее). Область для ввода названия метки, если не вводить, то вместо названия будет адрес. Переключателя комментарий/список, в зависимости от положения показывается либо поле для комментария, либо поле создания списка. Ниже находится область поиска, которая позволяет найти место на карте или из ранее заданных меток. Справа от него находится кнопка доступа к избранным местам. Ниже находятся кнопка перехода к экрану выбора оповещений, а слева два индикатора отображающие включенные оповещения. Далее находится поле ввода количества срабатываний метки. По умолчанию стоит число 1 и после срабатывания метки она становится не активна. Если снять поставить чекбокс в неактивное состояние, то метка будет срабатывать каждый раз. Далее поля выбора границ по времени и дате. В самом низу находится кнопка завершения создания/редактирования метки.

Экран Settings.

Рисунок 18 Экран Settings.

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

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

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

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

GPS (Global Positioning System) — система спутниковой навигации, предоставляющая возможность определения времени, изменения расстояния и местоположения. В современных девайсах используется в сочетании с российской системой ГЛОНАСС, модули находятся на одном чипе и используют обе группы спутников.

A-GPS (Assisted GPS) — технология позволяющая определять местоположение клиента используя вышки мобильной связи. Основная цель технологии в ускорении холодного старта GPS, но так же способна самостоятельно предоставлять координаты с точностью от 20 до 2000 метров в зависимости от количества близлежащих вышек. В отличии от GPS данные о место положении вычисляет сотовая сеть, а не устройство, что требует наличия интернет соединения для передачи сведений о локации и обновлении альманаха.

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

В принципиальной основе приложения лежит то, что оно работает постоянно, и имея возможность снять вычислительную нагрузку с устройства, имеет смысл ей воспользоваться. Из этого можно ввести ещё одно правило в алгоритм: Если, учитывая предоставляемую A-GPS погрешность, расстояние до ближайшей метки в три раза больше, чем погрешность A-GPS, то следует рассчитывать время следующего определения местоположения, основываясь на полученных данных, максимально компенсируя погрешность в сторону уменьшения времени следующего запроса о положении. Стоит отметить, что при нахождении пользователя ближе 2000 метров к ближайшей отметке, погрешность A-GPS может привести к несвоевременному срабатыванию, в этом случае сервис переключается в работу сервиса.

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

Зная нынешние координаты, мы можем вычислить расстояние до метки, вычитанием координат (в случае с A-GPS вычитается дельта погрешности), так же следует вычесть радиус метки, чтобы получить расстояние до точки срабатывания. Чтобы получить из расстояния время следует его разделить на скорость.

Используя A-GPS и GPS, мы можем выявить два вида скорости. Первая — это скорость в данный момент времени, V_{моментальная}. Вторая — средняя скорость за время прошедшее после последнего получения координат, получаемая делением расстояния на время полученное между геоданными, V_{промежуточная} для случаев, когда пользователь передвигаясь на транспорте сделал остановку и в это время произошел запрос геопозиции. Третья — средняя предполагаемая скорость, предполагая использование этой программы в населенных пунктах и их окрестностях её решено взять равной 75 км/ч, V_{ожидаемая}, для случаев, когда пользователь может начать движение в момент после расчета геопозиции. Для расчета будет использоваться наибольшая скорость, во избежание позднего замера положения пользователя.

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

Для обоснования логики поведения системы вблизи метки следует рассмотреть разные ситуации.

Ситуация 1:

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

Ситуация 2:

Пользователю по приходу на работу необходимо написать письмо, но перед работой он заходит в кафе позавтракать на 30 минут, при этом кафе не находится в зоне метки, а на расстоянии 500 метров.

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

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

Находясь во второй ситуации в течение 30 минут, мы будем получать одно и то же значение положения устройства плюс погрешность GPS. Из этого следует, что будет логично, получая в трех и более запросах один результат перевести расчет времени в режим ожидания с ограничением запросов не чаще, чем каждые 1−3 минуты в зависимости от расстояния до метки и выйти из этого режима, сразу после начала движения.

Рисунок 19 Алгоритм вычисления времени до следующего запрса геопозиции Где DMM — координаты положения пользователя, S — расстояние до метки, tg — время до запроса геоданных, Vm — скорость моментальная, Vп — скорость промежуточная, Vo — скорость ожидаемая.

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

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

Рисунок 20 Фрагменты видеосъемки процесса тестирования Слева на право: Hypocampo, Геопланировщик и прототип разрабатываемого сервиса.

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

Hypocampo.

• 1) Попытки создать геометку в разделе обычных задач;
• 2) Сложности в становлении метки на карте из-за неотзывчивости системы;
• 3) Попытки закончить становление метки без имени, что вызывало ошибку программы;