Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Часть 3. Оценка и улучшение ПИ.

Читайте также:
  1. I часть
  2. I. Самооценка
  3. II часть
  4. II. Основная часть. Марксистская школа.
  5. II. Практическая часть
  6. II. Практическая часть
  7. II. Практическая часть

Критерии оценки интерфейса Существует четыре основных (все остальные– производные) критерия качества любого интерфейса, а именно:

· скорость работы пользователей.

· количество человеческих ошибок.

· скорость обучения.

· субъективное удовлетворение.

Скорость выполнения работы. Критерий скорости работы удостоился определенного почета: для его оценки был выведен чуть ли не единственный в интерфейсной науке неэвристический метод, называемый GOMS
Согласно Дональду Норману, взаимодействие пользователя с системой (не только компьютерной) состоит из семи шагов:

1. формирование цели действий

2. определение общей направленности действий

3. определение конкретных действий

4. выполнение действий

5. восприятие нового состояния системы

6. интерпретация состояния системы

7. оценка результата.

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

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

Итак, для продолжения работы пользователь должен знать:

· на каком шаге он остановился

· какие команды и параметры он уже дал системе

· что именно он должен сделать на текущем шаге

Длительность физических действий.
Длительность физических действий пользователя, прежде всего, зависит от степени автоматизации работы и степени необходимой точности работы.
Еще в 1954 году Поль Фитс (Paul Fitts) сформулировал правило, в наиболее практичной формулировке ставшее известным как Закон Фитса:

Время достижения цели прямо пропорционально дистанции
до цели и обратно пропорционально размеру цели.

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

Ошибки.
Важным критерием эффективности интерфейса является количество человеческих ошибок.

Попробуем классифицировать причины человеческих ошибок, и подумаем, как с ними бороться:

· Ошибки, вызванные недостаточным знанием предметной области

· Опечатки

· Несчитывание показаний системы

· Моторные ошибки

при борьбе с ошибками нужно направлять усилия на:

· плавное обучение пользователей в процессе работы

· снижение требований к бдительности

· повышение разборчивости и заметности индикаторов.

а также необходимо не забывать о снижении чувствительности системы к ошибкам для чего есть 3 подхода:

· блокировка потенциально опасных действий пользователя до получения подтверждения правильности действия

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

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

Экспертная оценка ПИ Весьма эффективным средством оценки получающегося интерфейса является его экспертная оценка. Часто оказывается, что сравнительно дорогое тестирование показывает то, что было бы легко видно постороннему, тем более вооруженному опытом и квалификацией, взгляду. Хотя экспертная оценка не может быть полноценной заменой тестирования, она обладает одним существенным преимуществом– для её проведения не требуется прототип. Это значит, что эксперт может быть приглашен на ранних стадиях работы, когда польза от обнаружения ошибок максимальна.

Для проведения экспертной оценки нужно знать следующее:

· Разные люди обнаруживают разные ошибки. Это значит, что метод работает лучше, когда количество экспертов больше единицы.

· Лучше привлекать несколько экспертов не одновременно, но последовательно.

· Чем больше информации о проектируемой системе будет предоставлено эксперту, тем более сложные проблемы он сможет выявить.

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

· Координаты всех людей, способных выполнить такую работу, можно найти на сайте www.usability.ru

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

1. Анкетирование пользователей, в которых пользователь дает оценку интерфейсу

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

3. Видеонаблюдения типичного использования системы.

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

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

 


Дата добавления: 2015-10-21; просмотров: 55 | Нарушение авторских прав


Читайте в этой же книге: Проектирование структуры программного продукта | Пользовательский интерфейс | Преимущества и недостатки стилей взаимодействия пользователя с системой. |
<== предыдущая страница | следующая страница ==>
Сообщения об ошибках.| Оценка трудоемкости разработки программного продукта

mybiblioteka.su - 2015-2024 год. (0.008 сек.)