Есть виндовый 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 по всем действиям пользователя в программе.

Здравствуйте, Mazay, Вы писали:
M>А кому сейчас легко . Zoom с быстрым возвратом можно считать "значимым" действием по получению информации.
M>Не понимаю проблемы с учётом состояния модели и представления — это ортогональные части общего состояния =). Общее состояние == их произведению.
Вот как раз с этим и проблема.
Смотри: я
1. открыл документ в ворде
2. сделал zoom:80%
3. набрал "привет"
4. Убедился, что видно хреново, и
5. сделал zoom:100%.

C точки зрения "произведения", никаких циклов в состоянии нет. Но если рассматривать состояние view отдельно, то видно, что я бегаю туда-сюда. Возможно, потому, что я ожидал уменьшения не текста, а самого UI.

M>ИМХО для такой задачи хорошо подойдёт DOM based UI, так как он уже даёт состояние представление описаное в виде одного документа.
Именно, что не хочется работать с произведением. Есть интуитивное предположение, что действовать нужно покомпонентно.
И может быть даже view state разделить на части: типа настройки тулбаров — отдельно от зума, и оба отдельно от задоканности окон и прочего.
M>Плюс выделение "значимых" действий позволит сделать классное глобальное UnDo по всем действиям пользователя в программе.
Ничего особенно классного не вижу. Отдельный undo по настройкам UI — это пожалуйста. А вот совместный... Этак чтобы вернуть нечаянно выключенный тулбар, я должен буду весь этот абзац тоже тово, откатить? Нет уж.

Как-то лет 10 назад, я имел наглость сболтнуть статистику работы пользователей в учетной системе. В одной очень блатной конторе, очень блатные пользователи в среднем 3-4 документа на человека в день проводили. Меня уволили. Лет через пять в некоторой мегакорпорации (олигарх которой сейчас имеет многомиллиардные финансовые трудности), я опять имел неосторожность высказать мнение начальничку, что когда супероператоры в день делают 10-20 документов, это очень мало. Меня послали хорическим матом. С тех пор я таких исследований не провожу.

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

S>Смотри: я
S>1. открыл документ в ворде
S>2. сделал zoom:80%
S>3. набрал "привет"
S>4. Убедился, что видно хреново, и
S>5. сделал zoom:100%.

S>C точки зрения "произведения", никаких циклов в состоянии нет. Но если рассматривать состояние view отдельно, то видно, что я бегаю туда-сюда. Возможно, потому, что я ожидал уменьшения не текста, а самого UI.
M>>ИМХО для такой задачи хорошо подойдёт DOM based UI, так как он уже даёт состояние представление описаное в виде одного документа.
S>Именно, что не хочется работать с произведением. Есть интуитивное предположение, что действовать нужно покомпонентно.
S>И может быть даже view state разделить на части: типа настройки тулбаров — отдельно от зума, и оба отдельно от задоканности окон и прочего.
Короче ясно что всё не просто. Какая задача, такой и гемор =)

M>>Плюс выделение "значимых" действий позволит сделать классное глобальное UnDo по всем действиям пользователя в программе.
S>Ничего особенно классного не вижу. Отдельный undo по настройкам UI — это пожалуйста. А вот совместный... Этак чтобы вернуть нечаянно выключенный тулбар, я должен буду весь этот абзац тоже тово, откатить? Нет уж.
Ааа. Ну если мыслить ширше и глубже, то обычный механизм Undo-Redo это вообще отстой, потому что линейный, потому что стэк. А должен быть деревянным, чтоб независимые действия можно было откатывать независимо:
1. Увеличил шрифт.
2. Сделал жирным.
3. Откатил увеличение шрифта. При этом шрифт остался жирным.

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

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

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

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

То, чо вы хотите увидеть — это чистое Юзабилити исследование. Как правило делается запись действий пользователя при помощи ScreenCam (например, софт от компании Camtasia) и одновременно видеозапись самого пользователя (например, при помощи вебкамеры). При этом обязательно пользователю выдается конкретное задание, которое он должен выполнить.

Далее просматриваются действия пользователя и анализируются:
— паразитные клики и движения мыши
— заведомо неверные действия
— лицо испытуемого и реакция на свои действия
— и так далее.

Вот пример такой записи, если интересно (сами можете посмотреть, как это происходит)

здесь

P.S. Желательно анализировать работу нескольких пользователей на одних и тех же заданиях.

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

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

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

S>То, чо вы хотите увидеть — это чистое Юзабилити исследование. Как правило делается запись действий пользователя при помощи ScreenCam (например, софт от компании Camtasia) и одновременно видеозапись самого пользователя (например, при помощи вебкамеры). При этом обязательно пользователю выдается конкретное задание, которое он должен выполнить.

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

Вот в этом именно в этом и мой вопрос:
S>Далее просматриваются действия пользователя и анализируются:
S>- паразитные клики и движения мыши
как автоматически распознать паразитный клик или нет, а движение мыши?

S>- заведомо неверные действия
как понять что действие неверное?

S>- и так далее.

S>Вот пример такой записи, если интересно (сами можете посмотреть, как это происходит)
S>здесь
Пытался — но винмеда плейр не дружит с моим интернетом — вот если было бы flash video.
Но это уже придирки — я такие видео уже видел раньше.

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

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

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

H>Что касается автоматизированного подхода (анализ движений мыши и т.п.), то ИМХО это не надежно. Примеры:
не надежно, но:

H>1. Пользователь оставил форму открытой и ушел пить чай. Он запутался/задумался?
ушел на 3 минуты? да просто выбрасывает данный случай (или эти 3 минуты) из набора данных.

H>2. Пользователь на минуту отвлекся, думая куда он вечером пойдет с женой — в кино, в гости, на каток и т.п. При этом он двигает список туда-сюда колесом прокрутки, бесцельно переключает чекбокс(ы) туда-обратно, в общем, развлекается как может. Все это внутри формы, наблюдаемой "очень умным алгоритмом".

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

H>3. Пользователь беседует по телефону и совершает бесцельные эволюции (см. выше) внутри наблюдаемой формы.
вот тут не знаю.

H>4. Пользователь накануне перепил и внимание/концентрация сильно снижены. Вводить новую категорию "пользователь с бодуна"?
тут тоже.

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

что такое фокус группа. пользователи объединенными общими целями с более менее одинаковым опытом? тогда да. все пользователи
предполагаются такими.

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

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

.
это я смотрел. интерфейс пока не польностью индуктивный — именно потому и нужны данные что именно неиндуктивно.

H>2. Для обратной связи? Здесь тоже есть стандартный и более надежный метод — оффлайн или онлайн опросы.
и для этого тоже.

H>3. Нечто третье?

скорее всего второе для обеспечения первого

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

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

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

я думал тут у кого то опыт в этом деле есть.

видимо я ошибался.

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

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

Ну или проще, анализировать нажатия на клавиатуру, то бишь, бац, и нажались одновременно 10 клавиш, значит бьет клаву, а бьет, значит любит

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

Желаю Вам успеха в решении этой задачи, в Вашем понимании и самой задачи, и ее успешного решения.

Но по-моему, самое разумное и к тому же самое простое — отслеживать обращения к кнопке/меню "Help", и все.

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

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

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

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

IS>ок. можно такое сделать — но много ли людей будут заполнять такую форму?
IS>в любом случае это можно использовать как еще один подход.
Как ни удивительно — заполняют. У нас на 30к пользователей (UK) около 5к анкет. Но это, конечно, зависит от характера программы.

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

IS>Есть виндовый UI — формы, поля ввода, лист боксы итп.
[skip]
IS>Спасибо.
Этот сайт software-testing.ru случаем не сможет помочь?

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

IS>как понять что действие неверное?
Hint: для начало надо знать намерения (задание) пользователя в конкретный момент времени, и какое действие является верным для выполнения этого намерения.

S>>- и так далее.

S>>Вот пример такой записи, если интересно (сами можете посмотреть, как это происходит)
S>>здесь
IS>Пытался — но винмеда плейр не дружит с моим интернетом — вот если было бы flash video.
Я при помощи Orbit закчал на hdd.

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

IS>>ок. можно такое сделать — но много ли людей будут заполнять такую форму?
IS>>в любом случае это можно использовать как еще один подход.
.>Как ни удивительно — заполняют.
Наверное, по инерции

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

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

Мне вспомнился Eclipse, который (вроде бы начиная с версии 3.4 Ganymede) периодически, при закрытии, спрашивает разрешения на отсылку usage data statistics. Видимо это что-то сродни тому, что реализуете вы. Может у них можно почерпнуть какие-то интересные идеи? Ходить сюда: http://www.eclipse.org/epp/usagedata/ .
Сорри если боян.

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

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

IS>>Есть виндовый UI — формы, поля ввода, лист боксы итп.
C>[skip]
IS>>Спасибо.
C>Этот сайт software-testing.ru случаем не сможет помочь?
а как он может помочь? там тестируют UI? кучей народа или экспертной оценкой?

кто пользовался — порекомендовать/отговорить можете?

спасибо.

Кстати, из личного опыта...

Все варианты описаны при условии, что посидеть и посмотреть, как пользователь работает, невозможно.

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

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

Третий вариант — спросить пользователя (а лучше десяток пользователей), что ему удобно, а что нет. Очень, кстати, действенный метод, особенно когда процентов 20-30 претензий пересекаются.

IS>Вот в этом именно в этом и мой вопрос:
S>>Далее просматриваются действия пользователя и анализируются:
S>>- паразитные клики и движения мыши
IS>как автоматически распознать паразитный клик или нет, а движение мыши?

S>>- заведомо неверные действия
IS>как понять что действие неверное?

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

Здесь, опять таки на беглый взгляд, можно думать о статистических показателях и их сравнивать. Например, разделение группы испытуемых (работающих) на более продвинутых и менее продвинутых и рассматривать статистическую разницу во времени между выполнением типовых задач. Так, к примеру, более подготовленные работают над созданием счета 5 минут, менее подготовленные — 10. А вот на создании платежки более подготовленные работают 7 минут, а менее подготовленные — 20. Явно видно, что в первом случает "процент отставания" 50%, а во второй 70%. Можно сделать вывод, что второе задание более трудно для менее подготовленных испытуемых (под подготовкой понимается не знание бизнес-лдогики, а общее владение компьютером. Хотя юизнес-логику тоже можно анализировать).

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

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