Есть виндовый UI — формы, поля ввода, лист боксы итп.

У пользователя есть клавиатуры и мышь.

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

Например

*прокручивает лист бокс туда-обратно
*делает паузы по 15 секунд между кликами
*паузы неравномерны по длине
*переключается между окнами не делая допольнительных кликов

итд — я думаю идея ясна.

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

Интересны книги, статьи, исследования и уже готовые реализации.

Спасибо.

Здравствуйте, Igor Sukhov, Вы писали:

Еще можно проверить, есть ли у пользователя микрофон, и анализировать то, что он говорит во время работы.
Если что-то вроде "what the fuck" или "че за на..." или "какой дятел это писал?!!", то факт запутанности пользователя можно считать установленным

Здравствуйте, akarinsky, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

A>Еще можно проверить, есть ли у пользователя микрофон, и анализировать то, что он говорит во время работы.
A>Если что-то вроде "what the fuck" или "че за на..." или "какой дятел это писал?!!", то факт запутанности пользователя можно считать установленным

ну насколько я знаю в IVR системах подобное уже давно используется, но мой вопрос — об Обычном. Настольном. Приложении.

Здравствуйте, akarinsky, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

A>Еще можно проверить, есть ли у пользователя микрофон, и анализировать то, что он говорит во время работы.
A>Если что-то вроде "what the fuck" или "че за на..." или "какой дятел это писал?!!", то факт запутанности пользователя можно считать установленным

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

Здравствуйте, Igor Sukhov, Вы писали:
IS>Есть виндовый UI — формы, поля ввода, лист боксы итп.
IS>У пользователя есть клавиатуры и мышь.
IS>Подскажите ссылки на алгоритмы и ислледования как понять что пользователь запутался в пользовательском интерфейсе или логике программы,
IS>базируюясь на его действиях или бездействии мышой и клавиатурой.
IS>Например
IS>*прокручивает лист бокс туда-обратно
IS>*делает паузы по 15 секунд между кликами
IS>*паузы неравномерны по длине
IS>*переключается между окнами не делая допольнительных кликов
IS>итд — я думаю идея ясна.
IS>Т.е. как понять состояние пользователя по движениями мыши, клавиатуры и паузах между действиями.
Описанные Вами действия пользователя можно считать вполне нормальными, они не означают,
"что пользователь запутался в пользовательском интерфейсе или логике программы".
Какой смысл Вашего исследования? Понять, что интерфейс или логика программы непонятны пользователям?
То, что непонятно одному пользователю может быть вполне понятно другому пользователю.

Здравствуйте, <Аноним>, Вы писали:

IS>>Есть виндовый UI — формы, поля ввода, лист боксы итп.
IS>>У пользователя есть клавиатуры и мышь.
IS>>Подскажите ссылки на алгоритмы и ислледования как понять что пользователь запутался в пользовательском интерфейсе или логике программы,
IS>>базируюясь на его действиях или бездействии мышой и клавиатурой.
IS>>Например
IS>>*прокручивает лист бокс туда-обратно
IS>>*делает паузы по 15 секунд между кликами
IS>>*паузы неравномерны по длине
IS>>*переключается между окнами не делая допольнительных кликов
IS>>итд — я думаю идея ясна.
IS>>Т.е. как понять состояние пользователя по движениями мыши, клавиатуры и паузах между действиями.
А>Описанные Вами действия пользователя можно считать вполне нормальными, они не означают,
кто это сказал?

А>"что пользователь запутался в пользовательском интерфейсе или логике программы".
кто такое сказал?

нужна аргументация.

А>Какой смысл Вашего исследования?
А>Понять, что интерфейс или логика программы непонятны пользователям?
да + нашупать подход на будущее.

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>Например
IS>*прокручивает лист бокс туда-обратно
IS>*делает паузы по 15 секунд между кликами
IS>*паузы неравномерны по длине
IS>*переключается между окнами не делая допольнительных кликов
IS>итд — я думаю идея ясна.

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

Кажись, низзя формализовать/алгоритмизировать состояние "пользователь запуталсо"
Разумнее понаблюдать за действиями...

Здравствуйте, <Аноним>, Вы писали:

IS>>Например
IS>>*прокручивает лист бокс туда-обратно
IS>>*делает паузы по 15 секунд между кликами
IS>>*паузы неравномерны по длине
IS>>*переключается между окнами не делая допольнительных кликов
IS>>итд — я думаю идея ясна.

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

А>Кажись, низзя формализовать/алгоритмизировать состояние "пользователь запуталсо"
знаю что можно — иначе бы не писал. конечно придется ввести допущения:

*condifence level
*типичность пользователя (например программа, одна из 10, к-й он используется каждый день)
*новизна программы — т.е. ожидается что пользователь будет себя вести так как он обычно ведет себя с новой программой

тем более что админы это не типичные пользователи. типичный пользователь — это офисный работник, не менеджер. таких 80 процентов.

А>Разумнее понаблюдать за действиями...
где аргументация?

p.s. и пожалуйста, без подонковскго новояза, в следущий раз. спасибо.

Здравствуйте, Igor Sukhov, Вы писали:

А>>Какой смысл Вашего исследования?
А>>Понять, что интерфейс или логика программы непонятны пользователям?
IS>да + нашупать подход на будущее.

А почему не пойти более простым путем — при закрытии формы (программы) выводить опросник в духе "вам было удобно?". Можно через web, консолидируя на сервере результаты опросов и в дальнейшем анализируя их.

Что касается автоматизированного подхода (анализ движений мыши и т.п.), то ИМХО это не надежно. Примеры:
1. Пользователь оставил форму открытой и ушел пить чай. Он запутался/задумался?
2. Пользователь на минуту отвлекся, думая куда он вечером пойдет с женой — в кино, в гости, на каток и т.п. При этом он двигает список туда-сюда колесом прокрутки, бесцельно переключает чекбокс(ы) туда-обратно, в общем, развлекается как может. Все это внутри формы, наблюдаемой "очень умным алгоритмом".
3. Пользователь беседует по телефону и совершает бесцельные эволюции (см. выше) внутри наблюдаемой формы.
4. Пользователь накануне перепил и внимание/концентрация сильно снижены. Вводить новую категорию "пользователь с бодуна"?

ИМХО, в рамках фокус-группы данный подход, наверное, вполне возможен (и то, в лучшем случае он будет лишь вспомогательным, т.к. большую ценность имеют все-таки живое общение, живые опросы и живое наблюдение). Но я так понимаю, предполагается использовать его не на фокус-группе, а на всех пользователях?

В общем, надо определиться, для чего все это нужно:
1. Для обучения или упрощения пользования программой? Но здесь это явный перебор, т.к. задача решается более, что ли, стандартными средствами... Смотрим в сторону индуктивного интерфейса

Автор(ы): Microsoft Corporation
Дата: 18.07.2005
Эта статья описывает новую модель пользовательского интерфейса, названную «индуктивный пользовательский интерфейс» (inductive user interface, IUI). Называемая также «индуктивной навигацией», IUI-модель показывает, как сделать прикладные программы более простыми, разбивая функциональность на экраны или страницы, которые проще как описывать, так и понимать. IUI-модель проявляется в разнообразных проектах Майкрософт, наиболее заметно — в Microsoft Money 2000. Данная статья является скорее введением в IUI, чем утвержденным и всесторонним набором рекомендаций и правил.

.
2. Для обратной связи? Здесь тоже есть стандартный и более надежный метод — оффлайн или онлайн опросы.
3. Нечто третье?

Здравствуйте, Igor Sukhov, Вы писали:

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

Здравствуйте, ., Вы писали:

.>Можно собирать статистику в каких полях/формах дольше всего сидит фокус, какие поля/формы используются чаще, етс. Средняя статистика позволит нивелировать влияние "ушел попить чаю".
Лучше просто отбрасывать 5% аномальных (слишком больших или слишком маленьких) результатов.

.>Правда обработка таких данных и интерпретация результатов вообще говоря нетривиальная задача.
Не такая уж и сложная

Мы инструментировали приложение, чтобы оно записывало координаты кликов, время между действиями и время нахождения на форме. Для их просмотра добавили простенький визуализатор, показывающий цветом горячие участки (на SWINGе это элементарно делается — с помощью glass pane, на которую рисуем с альфа-каналом).

Здравствуйте, Cyberax, Вы писали:

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

А какие выводы можно сделать, зная, что какой-то контрол более "горячий", чем другие? ИМХО, только то, что он чаще всего используется. Но об эффективности это мало что скажет. Можно, например, заставить перед любым действием на форме нажимать специальную кнопку. Пользователь, проклиная все на свете, будет остервенело кликать эту злосчастную кнопку. Мы увидим цветастую диаграмму, где эта кнопка самая "горячая". Дальше-то что?

Здравствуйте, Hawk, Вы писали:

H>А какие выводы можно сделать, зная, что какой-то контрол более "горячий", чем другие? ИМХО, только то, что он чаще всего используется. Но об эффективности это мало что скажет. Можно, например, заставить перед любым действием на форме нажимать специальную кнопку. Пользователь, проклиная все на свете, будет остервенело кликать эту злосчастную кнопку. Мы увидим цветастую диаграмму, где эта кнопка самая "горячая". Дальше-то что?
Нам помогло понять какие действия пользователя больше всего занимают времени. Было несколько удивительных открытий. Оказалось, например, что в одном окне пользователи много времени тратили на изменение размеров splitter'а. После того, как добавили интеллектуальный алгоритм его масштабирования — нам даже благодарственные письма писать стали.

Ну и по мелочам много чего нашли.

Здравствуйте, Igor Sukhov, Вы писали:

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

Голубая мечта маркетолога

Автор: Sergey Soloviev
Дата: 11.12.06

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

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

Здравствуйте, Hawk, Вы писали:

H>А какие выводы можно сделать, зная, что какой-то контрол более "горячий", чем другие? ИМХО, только то, что он чаще всего используется. Но об эффективности это мало что скажет. Можно, например, заставить перед любым действием на форме нажимать специальную кнопку. Пользователь, проклиная все на свете, будет остервенело кликать эту злосчастную кнопку. Мы увидим цветастую диаграмму, где эта кнопка самая "горячая". Дальше-то что?
Вот я как раз об этом. Решить что делать с результатами — самая большая сложность.
Тут уже нужно смотреть приложение. Скажем, если на форме 5 альтернативных кнопок, но первая нажимается в 95% случаях, то логично убрать эти кнопки и сделать выбор 1 по умолчанию, а остальные — вынести в дополнительные опции, в меню какое-нибудь.
С другой стороны нужно думать, а почему оно так нажимается. Может просто 95% пользователей используют эту кнопку, т.к. они юзеы-"любители", им остальное и не нужно, а профессионалам, которых 5%, нужны все эти кнопки одновременно. Тогда может стоит делать 2 вида интерфейса.

Это не ответ на вопрос, просто возникают 2 мысли.

Не исключено, что частично придется анализировать активность юзера за компом в целом, не только в нашем приложении. Это из-за того, что юзер не сидит в лаборатории под присмотром. К тому же наше приложение может взаимодействовать с другими, и суета юзера (в т.ч. ошибки) может возникнуть из-за других приложений (копипаст, экспорт-импорт, обращение к хелпу и т.п.). Но все будет похоже на спайварь.

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

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

Здравствуйте, goto, Вы писали:

G>Не исключено, что частично придется анализировать активность юзера за компом в целом, не только в нашем приложении. Это из-за того, что юзер не сидит в лаборатории под присмотром. К тому же наше приложение может взаимодействовать с другими, и суета юзера (в т.ч. ошибки) может возникнуть из-за других приложений (копипаст, экспорт-импорт, обращение к хелпу и т.п.). Но все будет похоже на спайварь.
Достаточно только отслеживать, пока наше окно является top-level. Все остальные факторы можно нивелировать размерами выборки.

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

Здравствуйте, Igor Sukhov, Вы писали:

Нужно выделить "значимые" действия пользователей и эээ... "шумовые". Например "значимые" действия: изменён шрифт текста, введено слово, изменена настройка, прочитана всплывающая подсказка, открыто окно с новой информацией (новой — в смысле эту информацию пользователь не видел уже 20 секунд, если человек 3 раза за 10 секунд откроет одно и тоже инфрмационное окно — это не "значимые действия"). "Шумовые" действия — перемещение мышки по меню, клики по контролам, прокрутка чего-нибудь, перемещение/ресайз окон.
Степень "запутаности" пользователя определяется отношением количства "шумовых" действий к "значимым" в единицу времени.

Если есть достаточно надёжное (в смысле достаточно общее, соответствующее представлению пользователя) понятие "состояния" программы, то можно отлавливать многократны возвраты к одному и тому же (опять же — в понимании пользователя) состоянию после нескольких "значимых" действий.

Здравствуйте, Mazay, Вы писали:

M>Нужно выделить "значимые" действия пользователей и эээ... "шумовые". Например "значимые" действия: изменён шрифт текста, введено слово, изменена настройка, прочитана всплывающая подсказка, открыто окно с новой информацией (новой — в смысле эту информацию пользователь не видел уже 20 секунд, если человек 3 раза за 10 секунд откроет одно и тоже инфрмационное окно — это не "значимые действия"). "Шумовые" действия — перемещение мышки по меню, клики по контролам, прокрутка чего-нибудь, перемещение/ресайз окон.
+ использование кнопки Cancel в модальных диалогах.
M>Если есть достаточно надёжное (в смысле достаточно общее, соответствующее представлению пользователя) понятие "состояния" программы, то можно отлавливать многократны возвраты к одному и тому же (опять же — в понимании пользователя) состоянию после нескольких "значимых" действий.
+; но это, имхо, труднодостижимо (не очень понятно, чем можно пренебречь, а чем нельзя. Нужно ли считать состояние view и состояние model частями одного состояния, или считать их ортогональными — чтобы, к примеру, детектировать попытки zoom с быстрым возвратом обратно).

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mazay, Вы писали:

M>>Нужно выделить "значимые" действия пользователей и эээ... "шумовые". Например "значимые" действия: изменён шрифт текста, введено слово, изменена настройка, прочитана всплывающая подсказка, открыто окно с новой информацией (новой — в смысле эту информацию пользователь не видел уже 20 секунд, если человек 3 раза за 10 секунд откроет одно и тоже инфрмационное окно — это не "значимые действия"). "Шумовые" действия — перемещение мышки по меню, клики по контролам, прокрутка чего-нибудь, перемещение/ресайз окон.
S>+ использование кнопки Cancel в модальных диалогах.
Угу. Если только пользователь не открыл их чтобы посмотреть какую-то информацию. По уму, конечно, эти вещи нельзя смешивать.
M>>Если есть достаточно надёжное (в смысле достаточно общее, соответствующее представлению пользователя) понятие "состояния" программы, то можно отлавливать многократны возвраты к одному и тому же (опять же — в понимании пользователя) состоянию после нескольких "значимых" действий.
S>+; но это, имхо, труднодостижимо (не очень понятно, чем можно пренебречь, а чем нельзя. Нужно ли считать состояние view и состояние model частями одного состояния, или считать их ортогональными — чтобы, к примеру, детектировать попытки zoom с быстрым возвратом обратно).
А кому сейчас легко . Zoom с быстрым возвратом можно считать "значимым" действием по получению информации.
Не понимаю проблемы с учётом состояния модели и представления — это ортогональные части общего состояния =). Общее состояние == их произведению.
ИМХО для такой задачи хорошо подойдёт DOM based UI, так как он уже даёт состояние представление описаное в виде одного документа.
Плюс выделение "значимых" действий позволит сделать классное глобальное UnDo по всем действиям пользователя в программе.