Хотелось бы знать, как можно решить подобную задачу (см. описание ниже). Свои решения имеются. Но хочется, чтобы посмотрели на задачу люди со стороны. Чтобы не навязывать свои решения, я опишу их чуть позже.
Задача: Навигационная система для КПК (с поддержкой GPS и GSM) должна включать модуль "поиск друзей". Функциональность этого модуля достаточно проста: любой пользователь системы может послать своему другу запрос (через СМС) о его местоположении. Получив такой запрос, пользователь может либо подтвердить его (т.е. навигационная система отсылает другу текущие координаты), либо отклонить (запрос остаётся без ответа).
Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.
При этом, хотелось бы избежать ситуации, когда пользователь, управляя машиной и двигаясь по маршруту, вынужден будет отвлекаться и подтверждать или отклонять запросы от своих друзей.
Другое обязательное условие: Ничто не должно отвлекать внимание пользователя, пока он управляет автомобилем.
Получается, что, с одной стороны, пользователь должен узнавать о том, что получены запросы от друзей, и утверждать ответы на них, а, с другой стороны, пользователь не должен узнавать о запросах, т.к. уведомления отвлекают его от процесса вождения. Ситуация ухудшается тем, что уведомление требует ответа (подтверждения или отказа) со стороны пользователя. Ваши предложения?
Здравствуйте, Rius, Вы писали:
R>подойдёт ли метод поиска устройств bluetooth?
Я тоже считаю такой метод оптимальным. Но задачедатель настаивает, чтобы подтверждение давалось на каждый запрос.
Здравствуйте, rusted, Вы писали:
R>навигатор читает запрос, водитель подтверждает/отклоняет голосом — это почти не отвлекает, и при этом удобнее всего.
А как сделать так, чтобы за подтверждение не был принят возглас кого-нибудь из пассажиров в машине?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>А как сделать так, чтобы за подтверждение не был принят возглас кого-нибудь из пассажиров в машине?
Я про распознование речи мало знаю, но думаю там есть способы "натренировать" систему, чтобы подходил голос только одного человека. И даже если так нельзя сделать с достаточной точностью, то всегда можно сказать, что это проблема водителя, если его пассажиры вместо него подтверждают запросы — пусть с ними и разбирается
Re[4]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, rusted, Вы писали:
R>Я про распознование речи мало знаю, но думаю там есть способы "натренировать" систему, чтобы подходил голос только одного человека. И даже если так нельзя сделать с достаточной точностью, то всегда можно сказать, что это проблема водителя, если его пассажиры вместо него подтверждают запросы — пусть с ними и разбирается
Спасибо! Ваше предложение интересно, но хотелось бы найти такое решение, которое не требовало бы чрезмерных затрат. Оно должно быть более-менее простое. Т.е. не должно слишком много времени уйти на research и кодирование. В идеале, к его реализации должно быть возможным приступить сразу.
К сожалению, я не уверен, что распознавание речи относится к таким решениям. Хотя, возможно, я и ошибаюсь.
Здравствуйте, rusted, Вы писали:
R>навигатор читает запрос, водитель подтверждает/отклоняет голосом — это почти не отвлекает, и при этом удобнее всего.
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>К сожалению, я не уверен, что распознавание речи относится к таким решениям. Хотя, возможно, я и ошибаюсь.
Распознавание команд значительно проще, чем распознавание речи в целом. Тем более, если распознавать нужно ровно одну команду. Тем более, если нужно распознавать одного человека. КЛ>Ещё раз, спасибо за помощь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Odi$$ey, Вы писали: OE>навигатор читает запрос, водитель подтверждает/отклоняет рычажком на руле (типа указателя поворотов)
Рычажок — это пять. Его можно вообще применять во всех остальных случаях, когда нужна обратная связь. "да"/"нет"/"повтори вопрос" будет работать на интуитивном уровне после очень небольшой тренировки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Sinclair, Вы писали:
S>Рычажок — это пять. Его можно вообще применять во всех остальных случаях, когда нужна обратная связь. "да"/"нет"/"повтори вопрос" будет работать на интуитивном уровне после очень небольшой тренировки.
Если GPS-навигатор встраивается в машину, то рычажок у руля очень даже кстати. Но мы рассматриваем ситуацию, когда навигационная программа продаётся отдельно, и может быть запущена практически на любом КПК с Windows Mobile (с поддержкой GPS и GSM). В этом случае, наличие дополнительного оборудования не очень кстати.
Давайте обострим задачу и поставим ещё одно ограничение: нельзя использовать дополнительное оборудование: рычажки, микрофоны и т.п. Можно только использовать, что и так уже есть: КПК и всё, что в нём — тач-скрин, стилус, GPS и GSM-модули, гарнитуру.
Первая пришедшая идея такова:
— при запросе координат пользователь получает звуковое сообщение вроде "Иван Петров запросил Ваши текущие координаты, отослать?";
— на экране коммуникатора появляется две иконки да/нет;
— когда пользователь имеет возможность он кликает по иконке.
Очевидных проблем три:
— клик отвлекает внимание и заставляет совершить некоторое действие, но, к счастью, время осуществления этого действия не велико и коммуникатор, обычно, находится в легко доступном месте в машине;
— пользователь может забыть о запросе контактов, а периодическое напоминание в неподходящий момент будет раздражать;
— за время появления возможности ответить может придти еще несколько запросов, их можно поместить в очередь.
ИМХО, голосовое подтверждение тоже не очень хороший вариант:
— во-первых, может быть ситуация, когда не до подтверждения координат и как будет трактовать полученный в этот момент ответ коммуникатор?;
— во-вторых, велика вероятность ложного или неправильного срабатывания, всё-таки шумоизоляция не у всех идеальная, да еще и музыка и пассажиры, кстати, у них тоже могут быть подобные устройства, и их жена тоже может в этот момент захотеть удостовериться, что они с друзьями в бане, а не едут на дачу.
Re: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Получается, что, с одной стороны, пользователь должен узнавать о том, что получены запросы от друзей, и утверждать ответы на них, а, с другой стороны, пользователь не должен узнавать о запросах, т.к. уведомления отвлекают его от процесса вождения. Ситуация ухудшается тем, что уведомление требует ответа (подтверждения или отказа) со стороны пользователя. Ваши предложения?
Хм... Вот чем придумывать каждому варианту недостатки — проведите испытания. Соберите в кучу все варианты решения, какие есть. Вроде по ходу беседы только три вырисовавается: голосовая команда; девайс на руле; и просто удобные большие кнопки на экране кпк, чтоб пальцем ткнуть. Сделайте прототип каждого варианта и покатайтесь по городу с каждым из них. Какой будет удобнее — такой и оставьте. А еще лучше — это если будут доступны все три варианта — на выбор пользователя.
Дело в том, что все озвучиваемые недостатки всех вариантов довольно субъективны. Основной недостаток — "неудобно". Но одному человеку ничего не стоит отвлечься от дороги на секунду и надавить на кнопку, а другому — это будет трудно. С голосовыми командами так же. Один предпочитает ездить в тишине — и голосовую команду дать — фигня, а другой заводит музыку на полную, и пытаться перекричать ее никакого желания у него нет.
Девайс на руль — отдельная песня. Это ведь не обязательно будет какое-то специализированное устройство под Вашу систему. Тема удобного пользования телефоном в машине как-то пока еще не полностью раскрыта. Мне бы вот было интересно поглядеть на какой-нить универсальный телефонный "контроллер", цепляющийся на руль. Например, чтоб звонки можно было с него делать. Или вот пришла смска (или мыло) — а ты надавил на кнопку и приятный (радостный, загробный — по вкусу) женский (мужской, детский — тоже по вкусу) голос тебе ее читает. Потом на другую кнопку надавил — и надиктовываешь ответ.
Re: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.
Ну а как же какие-нить постоянные правила/политики? Допустим, я жене своей доверяю, и пусть она сколько угодно смотрит, где я нахожусь — не жалко. А вот коллеге своему настырному — хрен я чего скажу. А шеф вообще пусть всегда думает, что я на даче где-нить. Под Владимиром. Короче, откуда такое обязательное требование взялось? Или это не от Вас зависит?
Re: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Кирилл Лебедев, Вы писали:
... КЛ>Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.
КЛ>При этом, хотелось бы избежать ситуации, когда пользователь, управляя машиной и двигаясь по маршруту, вынужден будет отвлекаться и подтверждать или отклонять запросы от своих друзей.
КЛ>Другое обязательное условие: Ничто не должно отвлекать внимание пользователя, пока он управляет автомобилем.
...
Навигатор так или иначе периодически привлекает к себе внимание и иногда требует взаимодействия. Если появляется новая функция, то потребуется дополнительное взаимодейтсвие. Т.е. хоть одно из условий будет, строго говоря, нарушаться.
Если по условию голосом управлять нельзя, никаго доп. хардвера нельзя, то можно минимизировать телодвижения.
— 2 тыка стилусом или пальцем куда попало в экран = "да", 3 тыка — "нет".
— Или сделать кнопки "да" и "нет" очень большими, вплоть до в полэкрана каждая. Можно использовать прозрачные кнопки, которые не будут закрывать карту.
Во-вторых, предопрепределенные ответы (редактируемый список):
— этим всегда отвечаем "да", не спрашивая;
— этим — всегда "нет";
— остальным — спрашиваем водителя.
Можно расширить возможности предопределенных списков:
— если запрашивает лучший друг, отправляем настоящие координаты;
— запрашивает жена, отсылаем координаты "а я на работе";
— любовница — "я у жены";
— начальник — "я уже в пути", "я в туалете" или "ничего не знаю, навигатор остался в машине, а машина припаркована возле офиса на соседней улице"
и т.п.
Т.е. таблица идентификатор запрашивающего и что делать(всегда "да"/всегда "нет"/спросить/послать такие-то координаты). Софт с такими фичами пойдет нарасхват, как горячие пирожки. Конечно это шутка большей частью, но при желании можно сделать максимально простой UI для настроек и оперативных ответов.
Re[2]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Mr.Cat, Вы писали:
MC>Хм... Вот чем придумывать каждому варианту недостатки — проведите испытания. Соберите в кучу все варианты решения, какие есть.
Тестировать хорошо уже отобранные варианты. А для того, чтобы их отобрать, их должно быть побольше (во всяком случае, не 2 и не 3).
Согласитесь, зачем я буду тестировать рычажок на руле, если заранее известно, что компания не будет поставлять каких-либо дополнительных устройств. Будет продаваться только программа. Рычажок хорош тогда, когда компания продаёт мультипродукт — программу + устройство под него. А здесь это не так.
Другое решение — это распознавание голосовой команды. Тут возможно тестирование. Но, опять-таки, время на research не должно быть большим. А в идеале, хорошо бы, чтобы research'а вообще не было.
MC>Вроде по ходу беседы только три вырисовавается: голосовая команда; девайс на руле; и просто удобные большие кнопки на экране кпк, чтоб пальцем ткнуть.
Решений гораздо больше. Просто на форуме пока привели 3.
Большие кнопки в навигационных системах делаются и так, т.к. большинство таких систем затачиваются под палец, а не под стилус. Выдача сообщения на экране плоха не тем, что сообщение маленькое (можно сделать и большое), а тем, что водитель вынужден отрывать свою взгляд от дороги, а руки — от руля. Кроме того, выводимое сообщение закрывает карту, положение машины на ней и указание по прохождению перекрёстка.
Основная задача навигационной системы — это всё-таки указывать дорогу. И другие задачи не должны каким-либо образом ухудшать качество решения этой основной задачи.
Здравствуйте, Mr.Cat, Вы писали:
MC>Ну а как же какие-нить постоянные правила/политики? Допустим, я жене своей доверяю, и пусть она сколько угодно смотрит, где я нахожусь — не жалко. А вот коллеге своему настырному — хрен я чего скажу. А шеф вообще пусть всегда думает, что я на даче где-нить. Под Владимиром. Короче, откуда такое обязательное требование взялось? Или это не от Вас зависит?
Такое решение уже было (самым первым). Я считаю его вполне работоспособным. Но есть правило, которое нельзя нарушать: любые приватные данные с телефона должны отсылаться только по подверждению пользователя. Местоположение пользователя относится к приватным данным.
Недостаток списка друзей заключается в том, что пользователь вносит в этот список людей лишь однажды. А затем может вполне забыть о том, кто находится в его списке. Если же пользователь подтверждает запрос вручную, то он непосредственно в данный момент знает, кому будут отосланы его текущие координаты.
Здравствуйте, goto, Вы писали:
G>Навигатор так или иначе периодически привлекает к себе внимание и иногда требует взаимодействия. Если появляется новая функция, то потребуется дополнительное взаимодейтсвие. Т.е. хоть одно из условий будет, строго говоря, нарушаться.
Не могу согласиться с тем, что навигатор отвлекает внимание пользователя. Наоборот, он помогает пользователю выполнять функцию управления автомобилем лучше и качественнее. В некоторых навигаторах голосовые подсказки доведены до такого совершенства, что пользователю не нужно смотреть на экран.
Здравствуйте, Кирилл Лебедев, Вы писали:
Но есть правило, которое нельзя нарушать: любые приватные данные с телефона должны отсылаться только по подверждению пользователя. Местоположение пользователя относится к приватным данным.
Кто придумал это правило? Вы? А Вы не задумывались над тем, что разграничение прав на основе правил — общепринятое решение для управления доступом к приватной информации. Примеров — множество. Фаерволы (кстати, применяемый во многих из них механизм близок к предлагаемому мной и не только мной решению), расшаренные файлы, даже в аське есть визибл и инвизибл листы. Это же не отменяет подтверждения для тех, для кого не созданы правила.
КЛ>Недостаток списка друзей заключается в том, что пользователь вносит в этот список людей лишь однажды. А затем может вполне забыть о том, кто находится в его списке.
Ну вот опять Вы про недостатки. Однажды внес, забыл, что внес и т.п. Сделайте прототип и протестируйте. Теоретическими измышлениями можно отбросить только варианты с критическими недостатками.
КЛ>Если же пользователь подтверждает запрос вручную, то он непосредственно в данный момент знает, кому будут отосланы его текущие координаты.
Ну так и для автоматически подтверждаемых и отклоняемых запросов можно пользователя уведомлять, мол "Ваша жена запросила ваше местоположение, и я сказал ей, что Вы на работе".
Re: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Получается, что, с одной стороны, пользователь должен узнавать о том, что получены запросы от друзей, и утверждать ответы на них, а, с другой стороны, пользователь не должен узнавать о запросах, т.к. уведомления отвлекают его от процесса вождения. Ситуация ухудшается тем, что уведомление требует ответа (подтверждения или отказа) со стороны пользователя. Ваши предложения?
Приходилось реализовывать похожую схему для одного байкерского клуба В итоге остановились на "исчезающем" списке друзей: когда пользователю приходит запрос на получение координат, он в ответ выбирает один из пунктов:
— отклонить запрос однократно
— передать однократно
— отклонять запрос в течении часа
— передавать в течении часа
— отклонять запрос следующие три часа.
— передавать следующие три часа.
Настройки эти относятся только к конкретному абоненту. Пункты передавать данные всегда и отклонять всегда осознано добавлять не стали, ибо чревато — очень легко забыть, что какой-то абонент в черном\белом списке. Сейчас еще просят добавить возможность объединять пользователей в группы, тоже временные.
И еще, по поводу удобства использования. Очень облегчают жизнь голосовые метки для контактов, то есть при входящем запросе такая метка воспроизводится и сразу понятно, от кого запрос — переводить взгляд на gps на надо. А если _весь_ экран разбивать на 6 частей и выделить их цветом, то для того, чтобы ткнуть пальцем и отвлекаться практически не приходится, моторная память очень быстро возникает.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Другое решение — это распознавание голосовой команды. Тут возможно тестирование. Но, опять-таки, время на research не должно быть большим. А в идеале, хорошо бы, чтобы research'а вообще не было.
Т.е. Вы собираетесь выпустить продукт, который не тестировался в условиях эксплуатации?
КЛ>Кроме того, выводимое сообщение закрывает карту, положение машины на ней и указание по прохождению перекрёстка.
Ну, сообщение выводить не обязательно (можно только звуком оповестить), запрет/разрешение можно и на аппаратные кнопки повесить. Причем можно сделать так, чтобы по умолчанию выполнялся, например, запрет, а разрешение — только по кнопке, мол "Жена запросила Ваше местоположение. Чтобы разрешить, нажмите кнопку такую-то, а иначе через двадцать секунд я ее на фиг пошлю".
Re[4]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Mr.Cat, Вы писали:
MC>Т.е. Вы собираетесь выпустить продукт, который не тестировался в условиях эксплуатации?
Я такого не писал.
MC>Ну, сообщение выводить не обязательно (можно только звуком оповестить), запрет/разрешение можно и на аппаратные кнопки повесить. Причем можно сделать так, чтобы по умолчанию выполнялся, например, запрет, а разрешение — только по кнопке, мол "Жена запросила Ваше местоположение. Чтобы разрешить, нажмите кнопку такую-то, а иначе через двадцать секунд я ее на фиг пошлю".
Я уже писал, что пользователь не должен отвлекаться от вождения, в том числе — отрывать руки от руля или от рычага переключения передач.
Здравствуйте, Mr.Cat, Вы писали:
MC>Кто придумал это правило? Вы? А Вы не задумывались над тем, что разграничение прав на основе правил — общепринятое решение для управления доступом к приватной информации.
Мой непосредственный начальник говорит, что это правило законодательно закреплено в странах ЕС. Я лично не проверял.
MC>Ну вот опять Вы про недостатки.
У каждого решения существуют свои ограничения. Я привожу Вам ограничения, потому что есть решения без них. На мой взгляд, они локально более идеальные, т.к. не требуют, дополнительных затрат. Т.е. не нужны дополнительные устройства и не нужно писать модуль распознавания голосовых команд.
Хотя решения с голосовыми командами и с рычажком у руля мне нравятся.
Здравствуйте, Conr, Вы писали:
C>И еще, по поводу удобства использования. Очень облегчают жизнь голосовые метки для контактов, то есть при входящем запросе такая метка воспроизводится и сразу понятно, от кого запрос — переводить взгляд на gps на надо. А если _весь_ экран разбивать на 6 частей и выделить их цветом, то для того, чтобы ткнуть пальцем и отвлекаться практически не приходится, моторная память очень быстро возникает.
У меня тоже появилась мысль уведомлять пользователя изменением цвета экрана, вернее цвета фона, карта при этом должна оставаться на экране. Но разбивать еще и разбивать экран на N частей — это круто, думаю это очень удобно. В итоге представляю себе такой интерфейс: по приходу смс-ки навигатор голосом уведомляет водителя и меняет цвет фона, цветом же экран разбивается на 3 активных области (цвета областей не должен сильно различаться, чтобы не затруднить восприятие карты). Если водитель занят то он просто игнорирует голосовое сообщение, но измененный цвет фона не дает ему забыть об смс-ке. Водитель может а) ткнуть пальцем в верхнюю половину экрана для повтора голосового оповещения, б) ткнуть пальцем в левый нижний угол для того что бы отослать свои координаты, в) — ткнуть в правый нижний угол для того, чтобы отреджектить запрос.
Получается графическое меню, на фоне которого отображается карта. Пункты меню занимают всю площадь экрана, визуально различаются немного разным цветом. Пункты не подписываются, роль подписей выполняет самый первый пункт, при клике по которому навигатор озвучивает контекст — "Вася Петров запросил ваши координаты, отослать?".
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Получается, что, с одной стороны, пользователь должен узнавать о том, что получены запросы от друзей, и утверждать ответы на них, а, с другой стороны, пользователь не должен узнавать о запросах, т.к. уведомления отвлекают его от процесса вождения. Ситуация ухудшается тем, что уведомление требует ответа (подтверждения или отказа) со стороны пользователя. Ваши предложения?
GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего).
Re[5]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Давайте обострим задачу и поставим ещё одно ограничение: нельзя использовать дополнительное оборудование: рычажки, микрофоны и т.п. Можно только использовать, что и так уже есть: КПК и всё, что в нём — тач-скрин, стилус, GPS и GSM-модули, гарнитуру. Тачскрин: сделать распознавание крупных жестов.
Типа слева по диагонали вниз направо — это Ok, а в противоположную сторону — это Cancel.
Идея в том, что в машине коммуникатор обычно в крэдле, и его можно нащупать не глядя. Попасть в маленькую кнопку тяжело, а вот жест, даже сильно искаженный, распознать легко. Гарнитура: задействовать стандартные кнопки "принять/отклонить вызов".
У этого решения вообще масса плюсов: есть стандартные аппаратные решения, которые размещают управление гарнитурой или громкой связью на руле, что сводит к идее с рычажком. При их отсутствии в любом случае гарнитура позволяет не глядя принять или отклонить запрос.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Usability для GPS-навигатора (реальная задача)
Задача поставлена не совсем корректно. Недостаточно информации для полного анализа.
К тому, что уже здесь преложили, могу добавить ещё один вариант.
Мобильная тусовка
Создаем некий диапазон "частот", номеров, пространство имен. Номера кажутся более логичными, но пространство имен дает возможность для фантазии.
Теоретически хостером может быть как выделенный сервер так и КПК определенного пользователя. Есть определенные удобства и в том и в другом случае.
Пользователи договариваются о тусовке на определенной "частоте", номере, нике. Все кто подключены к этому номеру видят друг-друга без дополнительных согласований на экране навигатора. При желании можно подключаться к нескольким тусовкам. Хочешь — создавай публичную тусовку и публикуй номер.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[2]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Gomes, Вы писали:
G>А можно передавать сразу пару-тройку предыдущих координат с определенным интервалом? Чтоб сразу было видно хотя бы в какую сторону движется.
Можно. Но такая передача должна быть утверждена пользователем.
. К сожалению, в задаче есть ограничение: каждая отправка координат должна подтверждаться пользователем.
Я не увидел ничего общего, как оно у вас совпало? А вообще мне кажется очень глупым что-то пытаться придумывать при отсутствующей постановке задачи. Извините за участие.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[2]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Sergei I. Gorelkin, Вы писали:
SIG>GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего).
Очень хорошее решение! Главное — оно использует то, что уже имеется — GPS-приёмник и информацию от него. Однако и данное решение можно ещё "дожать" и усилить. Интересно, кто-нибудь сделает следующий шаг?
Здравствуйте, grosborn, Вы писали:
G>Я не увидел ничего общего, как оно у вас совпало?
Общее в решениях то, что в каждом конкретном случае решение принимает не пользователь, а программа. Пусть на основе созданных групп, предопределённых правил и т.п., но программа. А надо, чтобы принимал пользователь.
G>А вообще мне кажется очень глупым что-то пытаться придумывать при отсутствующей постановке задачи. Извините за участие.
На мой взгляд постановка достаточно полна — описана проблема + даны ограничения. Если Вам какой-то информации не хватает, пожалуйста, укажите какой. Я постараюсь дополнить описание задачи.
Здравствуйте, Кирилл Лебедев, Вы писали:
SIG>>GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего). КЛ>Очень хорошее решение! Главное — оно использует то, что уже имеется — GPS-приёмник и информацию от него. Однако и данное решение можно ещё "дожать" и усилить. Интересно, кто-нибудь сделает следующий шаг?
Не хочу разочаровывать, но следующий шаг делать надо очень осторожно Просто потому, что определение скорости по GPS в реальном времени очень неточно. Она меряется не по треку (координатам), а с помощью эффекта Доплера, то есть мы получаем "доплеровскую скорость". В итоге появляется слишком много факторов, влияющих на точность измерений и предсказать\предусмотреть их воздействие не представляется возможным.
Вот парочка исследований, можно на досуге ознакомиться: A GPS Velocity Sensor: How Accurate Can It Be? – A First Look GPS and speed measurements
PS. На практике, если едешь по трассе без резких маневров (ускорений, поворотов, торможений и тп), то доплеровская скорость измеряется весьма точно, погрешность не больше 1 км\ч, но вот в городе или, что много хуже, в горах на серпантине, погрешность дитчайшая. Похоже, этот способ измерений совсем не рассчитан на изменение вертикальной составляющей. Можно сделать опыт: берем GPS и, стоя на месте, подбрасываем его вертикально вверх, метра на 1.5 — он покажет скорость в 50-60 км, даже если надежно подцепился к нескольким спутникам.
PPS. Мерить скорость координатным методом, по трекам, тоже не получается, потому что нам нужна краевая скорость — на конце трека, а эти данные тоже грешат неточностью.
Re[4]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Conr, Вы писали:
C>Не хочу разочаровывать, но следующий шаг делать надо очень осторожно Просто потому, что определение скорости по GPS в реальном времени очень неточно. Она меряется не по треку (координатам), а с помощью эффекта Доплера, то есть мы получаем "доплеровскую скорость". В итоге появляется слишком много факторов, влияющих на точность измерений и предсказать\предусмотреть их воздействие не представляется возможным.
Спасибо! О погрешности GPS мне известно. Но интересна модель приведённого решения. Используя эту модель, решение можно "дожать" и избавить от недостатков, связанных с погрешностью определения скорости.
SIG>>GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего). КЛ>Очень хорошее решение! Главное — оно использует то, что уже имеется — GPS-приёмник и информацию от него. Однако и данное решение можно ещё "дожать" и усилить. Интересно, кто-нибудь сделает следующий шаг?
Делаю следующий шаг (сразу в "Коллеги, улыбнитесь" )
Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет")
Зато никаких дополнительных устройств не надо
Re[4]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Аноним, Вы писали:
А>Делаю следующий шаг (сразу в "Коллеги, улыбнитесь" ) А>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") А>Зато никаких дополнительных устройств не надо
Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой:
1. пришло уведомление
2. воспроизводится голосовая метка
3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет.
Погрешность доплеровской скорости в этой ситуации можно нивелировать: нам же надо получать не абсолютные показатели, а всего-лишь определить изменение... можно фильтр Калмана использовать. Нет, определенно, спасибо за идею На выходных реализую, посмотрим что получится.
Re[5]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Conr, Вы писали:
А>>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") C>Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой: C>3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет.
Здравствуйте, Аноним, Вы писали:
А>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") А>Зато никаких дополнительных устройств не надо
Смех-смехом, но вот решение Odi$$ey'я
очень близко к тому, что описали Вы. Вы описали идеальное решение, когда никаких других устройств не нужно, а Odi$$ey сделал небольшой шажок назад (ввёл кнопку, которая крепится к рулю). Если вместо кнопки или машины выбрать другой ресурс (из тех, что есть), то получится другое решение, которое тоже является идеальным (или близким к нему).
Здравствуйте, Хитрик Денис, Вы писали:
А>>>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") C>>Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой: C>>3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет.
ХД>Да не дай бог такое управление!
Мне попробовать интересно, чисто технически. Да и не на машине же я, а мотоцикл окружающим при таких маневрах мешать не будет.
Re[7]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Conr, Вы писали:
А>>>>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") C>>>Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой: C>>>3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет. ХД>>Да не дай бог такое управление! C>Мне попробовать интересно, чисто технически. Да и не на машине же я, а мотоцикл окружающим при таких маневрах мешать не будет.
Ещё можно тормозом морзянку выстукивать. СМСки набирать
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Аноним, Вы писали:
А>>Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет") А>>Зато никаких дополнительных устройств не надо КЛ>Смех-смехом, но вот решение Odi$$ey'я
очень близко к тому, что описали Вы. Вы описали идеальное решение, когда никаких других устройств не нужно, а Odi$$ey сделал небольшой шажок назад (ввёл кнопку, которая крепится к рулю). Если вместо кнопки или машины выбрать другой ресурс (из тех, что есть), то получится другое решение, которое тоже является идеальным (или близким к нему).
КЛ>Спасибо!
Идея с вилянием мне, признаться, тоже приходила в голову, но я счел ее слишком передовой для публикации в этом топике.
У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно)).
Re[5]: Usability для GPS-навигатора (реальная задача)
очень близко к тому, что описали Вы. Вы описали идеальное решение, когда никаких других устройств не нужно.
Решение остроумное и оригинальное! Но это решение не той задачи. Требование не использовать дополнительные органы управления — это следствие более важного требования: не отвлекать водителя от вождения. И решение этому более важному требованию не удовлетворяет. Не знаю как ездит остальной народ, но лично для меня выполнение резких незапланированных маневров требует бОльшей концентрации внимания, чем тыканье кнопок на руле (на гарнитуре, на экране навигатора). Как минимум мне нужно оглянуться (не забываем про мертвые зоны) и проверить, достаточно ли вокруг пространства для безопасного выполнения маневра, тем более если речь идет о езде в городском потоке.
Здравствуйте, goto, Вы писали:
G>Идея с вилянием мне, признаться, тоже приходила в голову, но я счел ее слишком передовой для публикации в этом топике.
Идея с вилянием автомобиля хороша не своим практическим смыслом (всё-таки главная задача пользователя — это управление автомобилем, и никакая необходимость ответить на запрос "друга" не должна мешать качественному выполнению этой задачи), а тем, что она подсказывает направление для идеального решения: когда из ресурсов используется то, что есть, и когда подтверждение или отклонение запроса выполняется заодно с другим действием, которое водитель, пользователь GPS-системы выполняет и так.
G>У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно)).
Лучше использовать более близкие к навигации (навигационной системе) объекты и действия. Например, задав себе вопрос "Что пользователь навигационной системы делает и так?", можно понять, совместно с какими действиями он может подтверждать или отклонять запросы.
Здравствуйте, seregaa, Вы писали:
S>Решение остроумное и оригинальное! Но это решение не той задачи. Требование не использовать дополнительные органы управления — это следствие более важного требования: не отвлекать водителя от вождения. И решение этому более важному требованию не удовлетворяет. Не знаю как ездит остальной народ, но лично для меня выполнение резких незапланированных маневров требует бОльшей концентрации внимания, чем тыканье кнопок на руле (на гарнитуре, на экране навигатора). Как минимум мне нужно оглянуться (не забываем про мертвые зоны) и проверить, достаточно ли вокруг пространства для безопасного выполнения маневра, тем более если речь идет о езде в городском потоке.
Согласен. Поэтому я и предлагаю использовать это "дикое" решение лишь, как некоторый ориентир. Этот ориентир можно использовать для получения других, олее работоспособных решений.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Согласен. Поэтому я и предлагаю использовать это "дикое" решение лишь, как некоторый ориентир. Этот ориентир можно использовать для получения других, олее работоспособных решений.
Здравствуйте, Кирилл Лебедев, Вы писали:
... G>>У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно)). КЛ>Лучше использовать более близкие к навигации (навигационной системе) объекты и действия. Например, задав себе вопрос "Что пользователь навигационной системы делает и так?", можно понять, совместно с какими действиями он может подтверждать или отклонять запросы.
Я начал постепенно догадываться, что мы участвуем в показательном семинаре-викторине по юзабилити. Не томите же, раскройте секреты фокусов, покажите наконец собственное красивое решение. Это может оказаться интересным. А аудитория ведь может и "перегореть" .
Re[6]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, goto, Вы писали:
G>У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно)).
Если не ошибаюсь, применение звуковых сигналов строго ограничено правилами — для предотвращения дтп.
Re[8]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, goto, Вы писали:
G>Я начал постепенно догадываться, что мы участвуем в показательном семинаре-викторине по юзабилити. Не томите же, раскройте секреты фокусов, покажите наконец собственное красивое решение. Это может оказаться интересным. А аудитория ведь может и "перегореть" .
Не совсем так. Задача, приведённая мной, вполне реальная. И она действительно требует решения. Я благодарен коллегам, которые привели красивые решения — такие, как:
кнопка у руля;
разделить экран на части и тыкать для подтверждения/отклонения запроса в определённую часть;
использовать язык жесток (касаний);
использовать голосовые команды.
Таких решений у меня не было. Другая часть решений совпала с моими. Конечно, у меня есть и другие решения. Они мне кажутся красивыми, но не факт, что они покажутся таковыми Вам или другим коллегам.
Тем не менее, я постараюсь их изложить и сделать резюме дискуссии в выходные — всё-таки такая работа требует времени.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>>Давайте обострим задачу и поставим ещё одно ограничение: нельзя использовать дополнительное оборудование: рычажки, микрофоны и т.п. Можно только использовать, что и так уже есть: КПК и всё, что в нём — тач-скрин, стилус, GPS и GSM-модули, гарнитуру. S>Тачскрин: сделать распознавание крупных жестов. S>Типа слева по диагонали вниз направо — это Ok, а в противоположную сторону — это Cancel. S>Идея в том, что в машине коммуникатор обычно в крэдле, и его можно нащупать не глядя. Попасть в маленькую кнопку тяжело, а вот жест, даже сильно искаженный, распознать легко.
проблема в том, что такой "жест" может быть истолкован двояко (как минимум), либо как ваше "ок", либо обычное "дрэгание" карты. Причем mousemove'ы приложению начнут приходить задолго до того, как вы доведете пальцем до правого нижнего угла -- и как приложению быть?.
возможные варианты:
1) начинать перетаскивание карты, а если движение дошло до конца экрана -- все отменять и обрабатывать команду "ок";
2) вообще не "дрэгаться" пока не палец/стилус не отпущен.
(что-то еще? ничего разумного в голову не приходит..)
Оба решения с точки зрения юзабилити навигатора -- кошмар.
Re[7]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, Sinclair, Вы писали:
S>Ок, снимаем предложение с жестами.
Не спешите отказываться от идеи только потому, что кажется, будто бы она вызывает проблемы. На самом деле, описанная проблема — лишь новая задача, которая, к тому же, имеет решение. Например, в навигаторе Tom-Tom карту можно перетаскивать только в специальном режиме — browse mode. А в режиме навигации карта не перетаскивается. Так что вполне можно использовать жесты.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Sinclair, Вы писали:
S>>Ок, снимаем предложение с жестами. КЛ>Не спешите отказываться от идеи только потому, что кажется, будто бы она вызывает проблемы. На самом деле, описанная проблема — лишь новая задача, которая, к тому же, имеет решение. Например, в навигаторе Tom-Tom карту можно перетаскивать только в специальном режиме — browse mode. А в режиме навигации карта не перетаскивается. Так что вполне можно использовать жесты.
Отлично, наличие такого режима это 3й вариант решения вышеописанной проблемы, к-рый я не предусмотрел.
С моей точки зрения это тоже не очень удачное решение. Это что же, чтобы мне посмотреть что находится чуть правее моего маршрута, по к-рому я еду -- мне надо по каким-то режимам переключаться? Еще, не дай бог, может быть ведение по маршруту отключать надо? И, наверное, это надо делать через какое-нибудь меню (читай -- более чем одним кликом в экран)?
С навигатором Tom-Tom не сталкивался, но, мне кажется, будет жутко неудобно.
з.ы. Кирилл, вы сами на практике пользовались gps-навигаторами (различными)? Какими именно, если не секрет?.
Re[10]: Usability для GPS-навигатора (реальная задача)
Здравствуйте, inko, Вы писали:
I>С навигатором Tom-Tom не сталкивался, но, мне кажется, будет жутко неудобно.
А зря. На текущий момент это самый популярный навигатор в Западной Европе и в Северной Америке. Заказчики приводят его в пример.
I>з.ы. Кирилл, вы сами на практике пользовались gps-навигаторами (различными)? Какими именно, если не секрет?.
Например, с tom-tom'ом.
"Рычажок — это пять. Его можно вообще применять во всех остальных случаях, когда нужна обратная связь. "да"/"нет"/"повтори вопрос" будет работать на интуитивном уровне после очень небольшой тренировки".
"Тачскрин: сделать распознавание крупных жестов. Типа слева по диагонали вниз направо — это Ok, а в противоположную сторону — это Cancel.
Идея в том, что в машине коммуникатор обычно в крэдле, и его можно нащупать не глядя. Попасть в маленькую кнопку тяжело, а вот жест, даже сильно искаженный, распознать легко".
У этого решения вообще масса плюсов: есть стандартные аппаратные решения, которые размещают управление гарнитурой или громкой связью на руле, что сводит к идее с рычажком. При их отсутствии в любом случае гарнитура позволяет не глядя принять или отклонить запрос".
" Первая пришедшая идея такова:
— при запросе координат пользователь получает звуковое сообщение вроде "Иван Петров запросил Ваши текущие координаты, отослать?";
— на экране коммуникатора появляется две иконки да/нет;
— когда пользователь имеет возможность он кликает по иконке.
Очевидных проблем три:
— клик отвлекает внимание и заставляет совершить некоторое действие, но, к счастью, время осуществления этого действия не велико и коммуникатор, обычно, находится в легко доступном месте в машине;
— пользователь может забыть о запросе контактов, а периодическое напоминание в неподходящий момент будет раздражать;
— за время появления возможности ответить может придти еще несколько запросов, их можно поместить в очередь".
"Ну а как же какие-нить постоянные правила/политики? Допустим, я жене своей доверяю, и пусть она сколько угодно смотрит, где я нахожусь — не жалко. А вот коллеге своему настырному — хрен я чего скажу. А шеф вообще пусть всегда думает, что я на даче где-нить. Под Владимиром".
"Недостаток списка друзей заключается в том, что пользователь вносит в этот список людей лишь однажды. А затем может вполне забыть о том, кто находится в его списке. Если же пользователь подтверждает запрос вручную, то он непосредственно в данный момент знает, кому будут отосланы его текущие координаты".
"Или сделать кнопки "да" и "нет" очень большими, вплоть до в полэкрана каждая. Можно использовать прозрачные кнопки, которые не будут закрывать карту".
" Во-вторых, предопрепределенные ответы (редактируемый список):
— этим всегда отвечаем "да", не спрашивая;
— этим — всегда "нет";
— остальным — спрашиваем водителя.
Можно расширить возможности предопределенных списков:
— если запрашивает лучший друг, отправляем настоящие координаты;
— запрашивает жена, отсылаем координаты "а я на работе";
— любовница — "я у жены";
— начальник — "я уже в пути", "я в туалете" или "ничего не знаю, навигатор остался в машине, а машина припаркована возле офиса на соседней улице"
и т.п.
Т.е. таблица идентификатор запрашивающего и что делать (всегда "да"/всегда "нет"/спросить/послать такие-то координаты). Софт с такими фичами пойдет нарасхват, как горячие пирожки. Конечно это шутка большей частью, но при желании можно сделать максимально простой UI для настроек и оперативных ответов".
"Приходилось реализовывать похожую схему для одного байкерского клуба В итоге остановились на "исчезающем" списке друзей: когда пользователю приходит запрос на получение координат, он в ответ выбирает один из пунктов:
— отклонить запрос однократно
— передать однократно
— отклонять запрос в течении часа
— передавать в течении часа
— отклонять запрос следующие три часа.
— передавать следующие три часа.
Настройки эти относятся только к конкретному абоненту. Пункты передавать данные всегда и отклонять всегда осознано добавлять не стали, ибо чревато — очень легко забыть, что какой-то абонент в черном\белом списке. Сейчас еще просят добавить возможность объединять пользователей в группы, тоже временные.
И еще, по поводу удобства использования. Очень облегчают жизнь голосовые метки для контактов, то есть при входящем запросе такая метка воспроизводится и сразу понятно, от кого запрос — переводить взгляд на gps на надо. А если _весь_ экран разбивать на 6 частей и выделить их цветом, то для того, чтобы ткнуть пальцем и отвлекаться практически не приходится, моторная память очень быстро возникает".
"У меня тоже появилась мысль уведомлять пользователя изменением цвета экрана, вернее цвета фона, карта при этом должна оставаться на экране. Но разбивать еще и разбивать экран на N частей — это круто, думаю это очень удобно. В итоге представляю себе такой интерфейс: по приходу смс-ки навигатор голосом уведомляет водителя и меняет цвет фона, цветом же экран разбивается на 3 активных области (цвета областей не должен сильно различаться, чтобы не затруднить восприятие карты). Если водитель занят то он просто игнорирует голосовое сообщение, но измененный цвет фона не дает ему забыть об смс-ке. Водитель может а) ткнуть пальцем в верхнюю половину экрана для повтора голосового оповещения, б) ткнуть пальцем в левый нижний угол для того что бы отослать свои координаты, в) — ткнуть в правый нижний угол для того, чтобы отреджектить запрос.
Получается графическое меню, на фоне которого отображается карта. Пункты меню занимают всю площадь экрана, визуально различаются немного разным цветом. Пункты не подписываются, роль подписей выполняет самый первый пункт, при клике по которому навигатор озвучивает контекст — "Вася Петров запросил ваши координаты, отослать?".
"GPS может определять скорость движения? Если да, то пусть действует в зависимости от скорости: если она больше пешеходной — делаем вывод, что хозяин за рулем, не отвлекаем его, другу можно отправить сообщение о том, что запрос будет обработан позже (можно и не отправлять ничего)".
"Пусть пользователь оказывает управляющее воздействие тоже с помошью автомобиля (например, повилял вправо-влево или сбросил-набрал скорость, и GPS это засек — считаем, что сказал "да", не изменяет курс — считаем, что сказал "нет"). Зато никаких дополнительных устройств не надо".
"Вообще идея очень хороша Мне понравилась. В итоге схема может быть такой:
1. пришло уведомление
2. воспроизводится голосовая метка
3. пользователь, если хочет разрешить передачу координат слегка притормаживает, если запретить, то увеличивает скорость или просто ее не меняет.
Погрешность доплеровской скорости в этой ситуации можно нивелировать: нам же надо получать не абсолютные показатели, а всего-лишь определить изменение... можно фильтр Калмана использовать. Нет, определенно, спасибо за идею На выходных реализую, посмотрим что получится".
ПРИМЕЧАНИЕ 2 к РЕШЕНИЮ 14 (автор – Кирилл Лебедев)
"Идея с вилянием автомобиля хороша не своим практическим смыслом (всё-таки главная задача пользователя — это управление автомобилем, и никакая необходимость ответить на запрос "друга" не должна мешать качественному выполнению этой задачи), а тем, что она подсказывает направление для идеального решения: когда из ресурсов используется то, что есть, и когда подтверждение или отклонение запроса выполняется заодно с другим действием, которое водитель, пользователь GPS-системы выполняет и так".
"Идея с вилянием мне, признаться, тоже приходила в голову, но я счел ее слишком передовой для публикации в этом топике.
У всех авто на руле уже есть одна подходящая кнопка — это бибикалка. Бибикаем раз — "yes", два — "no". А дальше — speech recognition (звук бибикалки она не спутает ни с радио, ни с разговором пассажиров, ни с бибикалками других авто (противное маловероятно))".
Создаем некий диапазон "частот", номеров, пространство имен. Номера кажутся более логичными, но пространство имен дает возможность для фантазии.
Теоретически хостером может быть как выделенный сервер так и КПК определенного пользователя. Есть определенные удобства и в том и в другом случае.
Пользователи договариваются о тусовке на определенной "частоте", номере, нике. Все кто подключены к этому номеру видят друг-друга без дополнительных согласований на экране навигатора. При желании можно подключаться к нескольким тусовкам. Хочешь — создавай публичную тусовку и публикуй номер".
В задаче нигде не говорится о том, что пользователь навигационной системы должен реагировать на запрос сразу. Если в момент поступления запроса пользователь занят вождением, то пусть он ответит тогда, когда у него появится свободное время.
Этого можно добиться несколькими способами:
Во-первых, пусть навигационная система уведомляет пользователя о поступивших запросах в момент остановки – навигатор может определить, что машина не движется (это потребует написания некоторой эвристики, но она будет не слишком сложна). (Здесь моё решение совпадает с решением 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-модуля: информация о запросах выдаётся пользователю при почти нулевой скорости.
На этом, думаю, всё.
Хочу поблагодарить всех коллег за плодотворное участие в обсуждении!
Ещё раз хочу поблагодарить вас за помощь в решении задачи. Задача реальна, т.е. проведённый опрос точно не был семинаром или подгонкой под известные решения. На текущий момент, с Вашей помощью удалось найти 17 решений. Все они описаны мною в дайджесте
. Так что теперь любой программист, столкнувшись с аналогичной задачей, может им воспользоваться. Ему будет достаточно только прочитать готовые решения и выбрать понравившиеся.
Если же ни одно решение в силу тех или иных причин не подойдёт, то можно будет придумать своё решение по аналогии или, воспользовавшись, приёмами (они тоже приведены здесь
Под приёмом я понимаю некоторую простейшую операцию (как правило, мысленную), которая, будучи применена к задаче, выводит на сильное решение. Например, приём "Вложенное действие" рекомендует совершать заданное действие вместе с каким-то другим действием, которое уже есть. Так, используя этот приём, можно прийти к решению, когда пользователь отклоняет или подтвердает запросы при любом обращении к навигационной системе. Т.е. любой диалог или меню навигатора содержит пункт "Подтвердить запросы" вместе с указанием количества не подтверждённых запросов.
