Человеко-машинное взаимодействие

1 Юзабилити-тестирование программного продукта. Назначение. Особенности

проведения.

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

Подготовка к тестированию:

1.Выявить цель. Начинать надо с общей цели.

2.Четко разбить цель на задачи.

3.Проектирование исследования:

·определить характеристики пользователей.

·определить структуру эксперимента.

·определить задание для участников тестирования.

·описать инструментарий исследования.

·определить требуемый персонал.

·выбрать участников тестирования

4.Проведение тестирования.

5.Подведение итогов тестирования.

6.Анализ полученных данных.

7.Поиск решения поставленных проблем.

Можно выделить следующие методики тестирования:

1.Метод фокусных групп.

2.Проверка посредством наблюдения пользователем.

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

Пример.

Устройство программ для проигрывания звуков на компьютере. Вся аудиотехника имеет почти одинаковый набор кнопок. Соответственно, при проектировании программы аналогичного назначения разумно скопировать существующую систему маркировки кнопок. Благодаря этому пользователям для использования программы ничему не приходится учиться.

Недостатки:

1.Не для любой функциональности можно подобрать подходящую метафору.

2.Даже подходящая метафора может оказаться бесполезной, если еѐ не знает существенная часть аудитории или еѐ тяжело однозначно передать интерфейсом.

3.Почти всегда метафора будет сковывать функциональные возможности.

Правила применения:

●опасно полностью копировать метафору, достаточно взять из неѐ самое лучшее;

●не обязательно брать метафору из реального мира, еѐ смело можно придумать самому;

●эффективнее всего метафорически объяснять значение отдельных объектов: например, для графической программы слои можно представлять как положенные друг на друга листы стекла (этот пример подходит и для предыдущего пункта);

●если метафора хоть как-то ограничивает систему, от неѐ необходимо немедленно

отказаться.

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

Идеома

Метафорическая парадигма - шаг вперед, потому что ее интуитивное понимание происходит без всякого знания механизма работы программ. Человек интуитивно понимает вещи мысленно сравнивая их с тем, что уже знает.

Пример

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

Если что-либо нельзя сделать «самопроизвольно» понятным, всегда можно сделать это везде одинаково, чтобы пользователи обучались только один раз. Например, кран с горячей водой всегда маркируют красным цветом, а кран с холодной – синим. Частично это соответствует свойствам человеческого восприятия (недаром красный цвет мы называем тѐплым, а синий – холодным), но в основном здесь работает привычка.

Стандарт хорошо работает, когда популярен, в противном случае не работает вовсе. Популярен же он может быть двумя способами: во-первых, он может быть во всех системах, вовторых, он может быть популярен внутри отдельной системы. Например, стандарт интерфейса MS Windows популярен почти во всех программах для Windows, именно поэтому его нужно придерживаться.

С другой стороны, этот стандарт оставляет неопределенным очень многое, и это многое в разных системах трактуется по-разному. Бесполезно пытаться найти общий знаменатель во всех системах, гораздо эффективнее установить собственный стандарт, не противоречащий стандарту ОС, но дополняющий его; после чего этого стандарта надо придерживаться.

3 Индикация процесса выполнения задачи в пользовательском интерфейсе.

Визуальные и звуковые методы. Сообщения об ошибках. Принципы и особенности применения.

В интерактивном процессе используются 2 типа визуальных элементов, а именно кнопки и индикаторы. Случаев, когда кнопка является также индикатором, следует, по возможности, избегать.

Существуют два основных критерия оценки эффективности интерактивного визуального элемента, это:

·качество/скорость восприятия элемента;

·физическая реализация элемента. Качество/скорость восприятия элемента

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

Причинами ухудшения восприятия элемента являются:

Ошибочно выбранный визуальный сюжет элемента.

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

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

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

Избыточная детализация сюжета.

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

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

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

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

Большинство сообщений об ошибках показывают пользователю, что система несовершенна, а именно:

недостаточно гибка, чтобы приспособиться к его действиям.

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

Типичное сообщение об ошибке, вызванное нежеланием системы показать пользователю границы его действий. К тому же из сообщения не понятно в чем собственно ошибка, а междометием «или» система расписывается в своей некомпетентности. Все усугубляется тем, что система не предоставляет ни одного варианта решения проблемы (еще бы! она ведь даже не знает точно, в чем она заключается). Даже опытный пользователь, впервые столкнувшись с этой проблемой, потратит на ее расшифровку несколько минут. Между прочим, это Office XP. Тескт ошибки «Значения левого и правого полей, промежутка между колонками или отступов абзацев слишком велики для заданной ширины страницы в некоторых разделах»

Следующая ошибка самоуверенна и считает, что пользователь дурак, которым можно и нужно помыкать. Пример подобного сообщения. Для кого неверное? И кто, собственно, виноват, система или пользователь? Текст ошибки «Указано неверное число»Как избежать сообщений об ошибках

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

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

Вреальной жизни любой объект или система, за исключением компьютерных программ, используют звук для позитивной обратной связи. Закрывая дверь, мы определяем, что она защелкнулась, услышав щелчок, тишина означает, что дверь еще не закрыта. Когда мы поворачиваем ключ зажигания и ничего не слышим, значит у нас проблемы. Когда мы включаем копир, а он молчит, вместо того, чтобы громко гудеть, мы понимаем, значит что-то не так.

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

Каким должно быть сообщение об ошибке

Существуют ситуации, в которых сообщение об ошибке не избежать. Типичные примеры подобных ситуаций: файл, находящийся на сетевом сервере более не доступен; попытка записи на диск, доступный только для чтения; недостаток нужных для работы программы компонентов, и т.д. Каким должно быть сообщение об ошибке в этом случае? Идеальное сообщение об ошибке должно отвечать всего на три вопроса:

1В чем заключается проблема?

2Как исправить эту проблему сейчас?

3Как сделать так, чтобы проблема не повторилась?

При этом отвечать на эти вопросы нужно возможно более вежливым и понятным пользователям языком.

Также необходимо помнить следующие общие правила:

●Никогда не забывайте показывать текст сообщений об ошибке техническому писателю;

●Всемерно старайтесь делать текст сообщения возможно более коротким.