Здравствуйте, 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%. Можно сделать вывод, что второе задание более трудно для менее подготовленных испытуемых (под подготовкой понимается не знание бизнес-лдогики, а общее владение компьютером. Хотя юизнес-логику тоже можно анализировать).

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

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