30 июня 2008 года на форуме RSDN.RU автором была размещена такая задача...
ЗАДАЧА
Уважаемые Коллеги!
Хотелось бы знать, как можно решить подобную задачу (см. описание ниже). Свои решения имеются. Но хочется, чтобы посмотрели на задачу люди со стороны. Чтобы не навязывать свои решения, я опишу их чуть позже.
Задача: Навигационная система для КПК (с поддержкой GPS и GSM) должна включать модуль "поиск друзей". Функциональность этого модуля достаточно проста: любой пользователь системы может послать своему другу запрос (через СМС) о его местоположении. Получив такой запрос, пользователь может либо подтвердить его (т.е. навигационная система отсылает другу текущие координаты), либо отклонить (запрос остаётся без ответа).
Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.
При этом, хотелось бы избежать ситуации, когда пользователь, управляя машиной и двигаясь по маршруту, вынужден будет отвлекаться и подтверждать или отклонять запросы от своих друзей.
Другое обязательное условие: Ничто не должно отвлекать внимание пользователя, пока он управляет автомобилем.
Получается, что, с одной стороны, пользователь должен узнавать о том, что получены запросы от друзей, и утверждать ответы на них, а, с другой стороны, пользователь не должен узнавать о запросах, т.к. уведомления отвлекают его от процесса вождения. Ситуация ухудшается тем, что уведомление требует ответа (подтверждения или отказа) со стороны пользователя. Ваши предложения?
ОБЗОР РЕШЕНИЙ
РЕШЕНИЕ 1
(автор – Rius)
"Подойдёт ли метод поиска устройств bluetooth?
* виден всем;
* скрыт новым, но виден ранее известным устройствам;
* скрыт ото всех".
РЕШЕНИЕ 2
(автор – rusted)
"Навигатор читает запрос, водитель подтверждает/отклоняет голосом — это почти не отвлекает, и при этом удобнее всего".
РЕШЕНИЕ 3
(автор – Odi$$ey)
"Навигатор читает запрос, водитель подтверждает/отклоняет рычажком на руле (типа указателя поворотов)".
ПРИМЕЧАНИЕ к РЕШЕНИЮ 3
(автор – Sinclair)
"Рычажок — это пять. Его можно вообще применять во всех остальных случаях, когда нужна обратная связь. "да"/"нет"/"повтори вопрос" будет работать на интуитивном уровне после очень небольшой тренировки".
РЕШЕНИЕ 4
(автор – Sinclair)
"Тачскрин: сделать распознавание крупных жестов. Типа слева по диагонали вниз направо — это Ok, а в противоположную сторону — это Cancel.
Идея в том, что в машине коммуникатор обычно в крэдле, и его можно нащупать не глядя. Попасть в маленькую кнопку тяжело, а вот жест, даже сильно искаженный, распознать легко".
РЕШЕНИЕ 5
(автор – Sinclair)
"Гарнитура: задействовать стандартные кнопки "принять/отклонить вызов".
У этого решения вообще масса плюсов: есть стандартные аппаратные решения, которые размещают управление гарнитурой или громкой связью на руле, что сводит к идее с рычажком. При их отсутствии в любом случае гарнитура позволяет не глядя принять или отклонить запрос".
РЕШЕНИЕ 6
(автор – Anry Spitsov)
" Первая пришедшая идея такова:
— при запросе координат пользователь получает звуковое сообщение вроде "Иван Петров запросил Ваши текущие координаты, отослать?";
— на экране коммуникатора появляется две иконки да/нет;
— когда пользователь имеет возможность он кликает по иконке.
Очевидных проблем три:
— клик отвлекает внимание и заставляет совершить некоторое действие, но, к счастью, время осуществления этого действия не велико и коммуникатор, обычно, находится в легко доступном месте в машине;
— пользователь может забыть о запросе контактов, а периодическое напоминание в неподходящий момент будет раздражать;
— за время появления возможности ответить может придти еще несколько запросов, их можно поместить в очередь".
РЕШЕНИЕ 7
(автор – Mr. Cat)
"Ну а как же какие-нить постоянные правила/политики? Допустим, я жене своей доверяю, и пусть она сколько угодно смотрит, где я нахожусь — не жалко. А вот коллеге своему настырному — хрен я чего скажу. А шеф вообще пусть всегда думает, что я на даче где-нить. Под Владимиром".
ПРИМЕЧАНИЕ к РЕШЕНИЮ 7
(автор – Кирилл Лебедев)
"Недостаток списка друзей заключается в том, что пользователь вносит в этот список людей лишь однажды. А затем может вполне забыть о том, кто находится в его списке. Если же пользователь подтверждает запрос вручную, то он непосредственно в данный момент знает, кому будут отосланы его текущие координаты".
РЕШЕНИЕ 8
(автор – goto)
"2 тыка стилусом или пальцем куда попало в экран = "да", 3 тыка — "нет".
РЕШЕНИЕ 9
(автор – goto)
"Или сделать кнопки "да" и "нет" очень большими, вплоть до в полэкрана каждая. Можно использовать прозрачные кнопки, которые не будут закрывать карту".
РЕШЕНИЕ 10
(автор – goto)
" Во-вторых, предопрепределенные ответы (редактируемый список):
— этим всегда отвечаем "да", не спрашивая;
— этим — всегда "нет";
— остальным — спрашиваем водителя.
Можно расширить возможности предопределенных списков:
— если запрашивает лучший друг, отправляем настоящие координаты;
— запрашивает жена, отсылаем координаты "а я на работе";
— любовница — "я у жены";
— начальник — "я уже в пути", "я в туалете" или "ничего не знаю, навигатор остался в машине, а машина припаркована возле офиса на соседней улице"
и т.п.
Т.е. таблица идентификатор запрашивающего и что делать (всегда "да"/всегда "нет"/спросить/послать такие-то координаты). Софт с такими фичами пойдет нарасхват, как горячие пирожки. Конечно это шутка большей частью, но при желании можно сделать максимально простой UI для настроек и оперативных ответов".
РЕШЕНИЕ 11
(автор – Conr)
"Приходилось реализовывать похожую схему для одного байкерского клуба В итоге остановились на "исчезающем" списке друзей: когда пользователю приходит запрос на получение координат, он в ответ выбирает один из пунктов:
— отклонить запрос однократно
— передать однократно
— отклонять запрос в течении часа
— передавать в течении часа
— отклонять запрос следующие три часа.
— передавать следующие три часа.
Настройки эти относятся только к конкретному абоненту. Пункты передавать данные всегда и отклонять всегда осознано добавлять не стали, ибо чревато — очень легко забыть, что какой-то абонент в черном\белом списке. Сейчас еще просят добавить возможность объединять пользователей в группы, тоже временные.
И еще, по поводу удобства использования. Очень облегчают жизнь голосовые метки для контактов, то есть при входящем запросе такая метка воспроизводится и сразу понятно, от кого запрос — переводить взгляд на gps на надо. А если _весь_ экран разбивать на 6 частей и выделить их цветом, то для того, чтобы ткнуть пальцем и отвлекаться практически не приходится, моторная память очень быстро возникает".
РЕШЕНИЕ 12
(автор – seregaa)
"У меня тоже появилась мысль уведомлять пользователя изменением цвета экрана, вернее цвета фона, карта при этом должна оставаться на экране. Но разбивать еще и разбивать экран на N частей — это круто, думаю это очень удобно. В итоге представляю себе такой интерфейс: по приходу смс-ки навигатор голосом уведомляет водителя и меняет цвет фона, цветом же экран разбивается на 3 активных области (цвета областей не должен сильно различаться, чтобы не затруднить восприятие карты). Если водитель занят то он просто игнорирует голосовое сообщение, но измененный цвет фона не дает ему забыть об смс-ке. Водитель может а) ткнуть пальцем в верхнюю половину экрана для повтора голосового оповещения, б) ткнуть пальцем в левый нижний угол для того что бы отослать свои координаты, в) — ткнуть в правый нижний угол для того, чтобы отреджектить запрос.
Получается графическое меню, на фоне которого отображается карта. Пункты меню занимают всю площадь экрана, визуально различаются немного разным цветом. Пункты не подписываются, роль подписей выполняет самый первый пункт, при клике по которому навигатор озвучивает контекст — "Вася Петров запросил ваши координаты, отослать?".
РЕШЕНИЕ 13
(автор – Sergei I. Gorelkin)
"GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего)".
РЕШЕНИЕ 14
(автор – Аноним 897)
"Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет"). Зато никаких дополнительных устройств не надо".
ПРИМЕЧАНИЕ 1 к РЕШЕНИЮ 14
(автор – Conr)
"Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой:
1. пришло уведомление
2. воспроизводится голосовая метка
3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет.
Погрешность доплеровской скорости в этой ситуации можно нивелировать: нам же надо получать не абсолютные показатели, а всего-лишь определить изменение... можно фильтр Калмана использовать. Нет, определенно, спасибо за идею На выходных реализую, посмотрим что получится".
ПРИМЕЧАНИЕ 2 к РЕШЕНИЮ 14
(автор – Кирилл Лебедев)
"Идея с вилянием автомобиля хороша не своим практическим смыслом (всё-таки главная задача пользователя — это управление автомобилем, и никакая необходимость ответить на запрос "друга" не должна мешать качественному выполнению этой задачи), а тем, что она подсказывает направление для идеального решения: когда из ресурсов используется то, что есть, и когда подтверждение или отклонение запроса выполняется заодно с другим действием, которое водитель, пользователь GPS-системы выполняет и так".
РЕШЕНИЕ 15
(автор – goto)
"Идея с вилянием мне, признаться, тоже приходила в голову, но я счел ее слишком передовой для публикации в этом топике.
У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно))".
РЕШЕНИЕ 16
(автор – grosborn)
"Мобильная тусовка.
Создаем некий диапазон "частот", номеров, пространство имен. Номера кажутся более логичными, но пространство имен дает возможность для фантазии.
Теоретически хостером может быть как выделенный сервер так и КПК определенного пользователя. Есть определенные удобства и в том и в другом случае.
Пользователи договариваются о тусовке на определенной "частоте", номере, нике. Все кто подключены к этому номеру видят друг-друга без дополнительных согласований на экране навигатора. При желании можно подключаться к нескольким тусовкам. Хочешь — создавай публичную тусовку и публикуй номер".
РЕШЕНИЕ 17
(автор – Кирилл Лебедев)
В задаче нигде не говорится о том, что пользователь навигационной системы должен реагировать на запрос сразу. Если в момент поступления запроса пользователь занят вождением, то пусть он ответит тогда, когда у него появится свободное время.
Этого можно добиться несколькими способами:
Во-первых, пусть навигационная система уведомляет пользователя о поступивших запросах в момент остановки – навигатор может определить, что машина не движется (это потребует написания некоторой эвристики, но она будет не слишком сложна). (Здесь моё решение совпадает с решением 13.)
Во-вторых, HUD навигационной системы может содержать что-то типа "почтового ящика" или "корзины сообщений". Когда сообщение приходит, оно помещается в корзину, а пользователь уведомляется звуковым сигналом. Как только пользователь освободится от вождения, он может тыкнуть на корзине и подтвердить или отклонить запросы. Необходимо только разработать такой дизайн HUD'а, чтобы корзина не загораживала карту.
В-третьих, навигационная система уведомляет пользователя о поступивших сообщениях тогда, когда он сам обращается к ней. Любой диалог навигатора может содержать поле "актуальные запросы", тыкнув на которые, пользователь может войти в меню "запросы", где подтвердить или отклонить каждый запрос.
Например, пользователь может обратиться к навигационной системе, чтобы найти ближайшие бензозаправки. Появится диалог поиска POIs (points of interest), в котором также будет уведомление о том, что ряд друзей желает узнать его координаты. Пользователь может либо проигнорировать запросы друзей и поискать бензозаправки, либо сначала подтвердить/отклонить запросы друзей, а затем – поискать бензозаправки.
Помимо уведомлений о поступивших запросах в диалогах, навигационная система может уведомлять пользователя и звуковым сигналом в момент поступления запроса. Однако пользователю вовсе необязательно сразу реагировать на этот запрос.
В-четвёртых, ряд навигационных систем при подъезде пользователя к перекрёстку, отображает перекрёсток на экране крупным планом. Это делается для того, чтобы пользователь мог хорошо разглядеть свой маршрут следования через перекрёсток. Этот крупный план может также содержать информацию о запросах. Не смотря на то, что такая информация будет находиться вне локуса внимания, пользователь может краем глаза заметить её и ответить тогда, когда будет свободен. (Данное решение, конечно, хорошо бы протестировать.)
ПРИМЕЧАНИЕ к РЕШЕНИЮ 17
(автор – Кирилл Лебедев)
Некоторые остальные мои решения совпали с решениями коллег – поэтому я их не стал приводить.
ОБЩИЙ КОММЕНТАРИЙ К РЕШЕНИЯМ
Данные решения интересны, но ещё более интересны приёмы, с помощью которых эти решения могут быть получены. Ниже привожу предварительные обобщения и приёмы.
ПРИЁМ 1
СДЕЛАТЬ ЗАРАНЕЕ
Формулировка приёма: Если нельзя выполнить какое-то действие в определённый момент времени, то его можно выполнить заранее.
1.1. Если человек внесён в список друзей, то координаты ему посылаются автоматически по его запросу.
1.2. Распределить людей по группам: одним – координаты посылаются автоматически, другим – отсылку координат нужно подтверждать, третьим – координаты не посылаются никогда.
1.3. Завести постоянные правила/политики, условия которых могут включать не только телефонные номера друзей, но и дни недели и т.п. В соответствии с этими правилами могут отсылаться не только реальные, но ложные координаты.
1.4. Распределить людей по группам и ограничить нахождение человека в группе определённым интервалом времени: час, 3 часа и т.п.
ПРИЁМ 2
СМЕНА КАНАЛА ВОСПРИЯТИЯ/ПОДТВЕРЖДЕНИЯ
Формулировка приёма: Если воздействие по определённому каналу неэффективно или неудобно, то следует воздействовать по другому каналу или по нескольким каналам сразу.
2.1. Навигатор читает запрос голосом, водитель – подтверждает или отклоняет тоже голосом.
2.2. Навигатор читает запрос голосом, водитель – подтверждает или отклоняет его при помощи специального рычажка у руля или при помощи стандартной кнопки на гарнитуре.
2.3. Навигатор читает запрос голосом, водитель – подтверждает или отклоняет его прикосновением к особому месту экрана или специальным жестом.
2.4. Навигатор издаёт звук поступления SMS и показывает уведомление в HUD'е. Пользователь подтверждает или отклоняет запрос в свободное время.
2.5. С каждым другом целесообразно ассоциировать определённую звуковую метку. При поступлении запроса от этого друга, проигрывается данная звуковая метка. Пользователь подтверждает или отклоняет запрос прикосновением к особому месту экрана или же при помощи специального жеста.
ПРИЁМ 3
ИСПОЛЬЗОВАНИЕ МОТОРНОЙ ПАМЯТИ
Формулировка приёма: Если необходимо, чтобы пользователь выполнял действия не глядя, то целесообразно свести их к очень небольшому и простому набору жестов.
3.1. Разбить экран навигатора на 4 – 6 крупных областей, в каждую из которых легко попасть пальцем не глядя. Тык пальцем в определённую область означает либо подтверждение, либо отклонение запроса.
3.2. Выводить диалог запроса с очень большими кнопками "Да" и "Нет", которые к тому же всегда находятся на одном и том же месте. Постепенно пользователь научится попадать в них не глядя.
3.3. Использовать язык жестов для подтверждения или отклонения запроса. Например, движение пальцем по горизонтали слева направо может означать подтверждение запроса, а движение в обратном направлении (справа налево) – отклонение.
ПРИЁМ 4
ВЛОЖЕННОЕ ДЕЙСТВИЕ
Формулировка приёма: Если нельзя выделить отдельное время на выполнение действия или для выполнения другого действия нельзя прерывать текущее действие, то другое действие следует выполнять параллельно с текущим.
4.1. Водитель подтверждает или отклоняет запрос параллельно с рулением при помощи специальной кнопки у руля.
4.2. Пользователь узнаёт о поступивших к нему запросах при обращении к навигационной системе: при показе любого диалога, при показе экрана с укрупнённым изображением перекрёстка, при показе карты по изменению цвета подложки.
4.3. Пользователь отвечает на запрос при выполнении любого обращения к навигационной системе, например, при поиске бензозаправки или кафе. Для этого информация о запросах должна встраиваться в любые диалоги.
ПРИЁМ 5
ИСПОЛЬЗОВАНИЕ РЕСУРСОВ
Формулировка приёма: Более эффективно использовать уже имеющиеся ресурсы, которые есть в системе, чем вводить дополнительные.
5.1. Для подтверждения или отклонения запроса использовать гарнитуру: одно нажатие на кнопку – подтверждение, двойное нажатие – отклонение.
5.2. Использование тач-скрина и языка жестов: горизонтальный жест слева направо – подтверждение запроса, а справа налево – отклонение.
5.3. Использование уже имеющихся диалогов: информация о поступивших запросах встраивается в уже существующие диалоги.
5.4. Использование цвета карты: при поступлении запросов цвет фона карты изменяется.
5.5. Использование GPS-модуля: информация о запросах выдаётся пользователю при почти нулевой скорости.
ПРИЁМ 6
ВЫПОЛНЕНИЕ ПРОТИВОРЕЧИВЫХ ДЕЙСТВИЙ В РАЗНЫЕ МОМЕНТЫ ВРЕМЕНИ
Формулировка приёма: Если противоречивые действия невозможно выполнить одновременно, то их следует выполнить в разные моменты времени.
6.1. Запросы от друзей накапливаются в некотором "ящике", водитель – подтверждает или отклоняет их, когда не занят вождением.
6.2. Навигатор выводит сообщения от друзей во время остановки (скорость движения некоторое время близка к нулю), пользователь – подтверждает или отклоняет запросы.
6.3. Навигатор показывает запросы от друзей в момент обращения пользователя к навигационной системе (например, при запросе определённых сведений или при попытке открыть диалог). В последнем случае, запросы встраиваются в диалог.
На этом, думаю, всё.
Хочу поблагодарить всех коллег за плодотворное участие в обсуждении!
Комментариев нет:
Отправить комментарий