Данная статья практически полностью основана на цитатах из книги Джефа Раскина Интерфейс новые направления в проектировании компьютерных систем с моими дополнениями и воссозданием приводимого в книге примера интерфейса.
Быстрый ответ на вопрос стоит ли использовать GOMS-анализ для проверки юзабилити: Если вы проектируете интерфейс, при работе с которым от задержки в 0,3 сек. никто не умирает не стоит..
Итак, The model of Goals, Objects, Methods, and Selection rules (GOMS) это метод исследования интерфейса, разработанный Кардом, Мораном и Ньюэллом в 80-х годах. GOMS позволяет предсказать, сколько времени потребуется опытному (именно опытному) пользователю на выполнение конкретной операции при использовании конкретного интерфейса.
Теперь, когда мы привыкли к этому странному для русского уха термину, можно описать его суть.
Разработчики GOMS заметили, что время на выполнение какой-то задачи пользователем, равно сумме всех временных интервалов, которые потребовались на выполнение каждого конкретного жеста пользователя (например, переместить руку с мыши на клавиатуру и набрать букву). С помощью лабораторных исследований был получен набор временных интервалов, требуемых для выполнения различных жестов.
Жесты и время по модели GOMS:
- H (перенос руки на мышь) = 0,4 сек
- К (нажатие клавиши клавиатуры или мыши) = 0,2 сек
- Р (перенос курсора к позиции на экране) = 1,1 сек
- М (обдумывание следующего шага) = 1,35 сек
- R (ожидание ответа системы) время зависит от быстродействия конкретной системы и не участвует в расчётах.
В дальнейших расчётах Жесты будут заменяться буквенными обозначениями из списка выше и будут называться Операторы.
Ниже пойдут довольно замысловатые правила работы с этими самыми жестами (операторами). Пока просто прочитайте их, а дальше я всё объясню на примере.
Правила расстановки операторов:
-
Правило 0. Начальная расстановка операторов M
Операторы M надо ставить перед всеми операторами K (нажатие клавиши), а также перед всеми операторами P (указание с помощью мыши), предназначенными для выбора команд (например, указание на выпадающий список); но перед операторами P, предназначенными для указания на аргументы этих команд (например, конкретный пункт в выпавшем списке), ставить оператор M не надо. -
Правило 1. Удаление ожидаемых операторов M
Если оператор, следующий за оператором M, является полностью ожидаемым с точки зрения оператора, предшествующего M, то этот оператор M может быть удален. Например, если вы перемещаете мышь чтобы нажать кнопку по достижении цели, то в соответствии с этим правилом следует удалить оператор M, устанавливаемый по правилу 0. -
Правило 2. Удаление операторов M внутри когнитивных
единиц
Если строка вида M K M K M K принадлежит когнитивной единице, то следует удалить все операторы M, кроме первого. Когнитивной единицей является непрерывная последовательность вводимых символов, например 4564.23 или Константин Константинопольский.
-
Правило 3. Удаление операторов M перед последовательными
разделителями
Если оператор K означает разделитель, стоящий в конце когнитивной единицы (например, тире между двумя днями понедельник четверг), то следует удалить оператор M, стоящий перед ним. -
Правило 4. Удаление операторов M, которые являются
прерывателями команд
Если оператор K является разделителем, стоящим после постоянной строки (например, точка в конце предложения, которая каждый раз вводится в неизменном виде), то следует удалить оператор M, стоящий перед ним. Добавление разделителя станет привычным действием, и поэтому разделитель станет частью строки и не будет требовать специального оператора M. Но если оператор K является разделителем для строки аргументов или любой другой изменяемой строки, то оператор M следует сохранить перед ним. -
Правило 5. Удаление перекрывающих операторов M
Любую часть оператора M, которая перекрывает оператор R, означающий задержку, связанную с ожиданием ответа компьютера, учитывать не следует.
Применение метода
Дано:
Юзера просят перевести температуру из Фаренгейта в Цельсий или наоборот. Например, могут попросить: Переведи, 3,5 градуса по Фаренгейту в градусы по Цельсию. Значение температуры юзер может ввести только с помощью клавиатуры или мыши.
Задача:
Спроектировать интерфейс, где время на перевод значений температуры минимально.
Условия
Для простоты, будем считать, что юзер вводит значения максимум из двух символов и юзер не совершает ошибок.
Важно: Приведённые ниже примеры служат именно для иллюстрации правил описанных в книге. Решить эту задачу можно было и другими, возможно более оптимальными, способами.
Решение. Вариант 1
Представим, что юзер сначала должен понять в какую сторону произойдёт перевод и если в нужную ему сторону, то просто вводит цифры. Если в не нужную сторону, то он переключается в радио-группе на нужную.
Расчёт:
Н (руку на мышь) + М (думаем) + Р (ведём курсор к радио-группе) + К (клик) + М (думаем) + Р (курсор к полю) + К (клик) + Н (перенос руки с мыши на клаву) + М (думаем) + К (ввод первой цифры) + М (думаем) + К (ввод второй цифры).
По правилу 2, удаляем лишние М и получаем:
Н + М + Р + К + М + Р + К + Н + М + К + К
Если выбрано НЕ подходящее направление конвертации температур, то получаем:
0,4 + 1,35 + 1,1 + 0,2 + 1,35 + 1,1 + 0,2 + 0,4 + 1,35 + 0,2 + 0,2 = 7,85 сек
Если выбрано подходящее направление конвертации температур, то получаем:
0,4 + 1,35 + 1,1 + 0,2 + 1,35 + 0,2 + 0,2 = 4,8 сек
Решение. Вариант 2
Выпиливаем необходимость переключать сторону перевода значений. Делаем поля ввода перетаскиваемыми. Если меняем положение / значение одного поля, то автоматически меняется и положение / значение другого.
Расчёт:
Н (0,4) + М (1,35) + Р (1,1) + К (0,2) + Р (1,1) = 4,15 сек
Этот вариант реализации юзабельней первого на 0,65 сек.
Погрешность метода
Раскин пишет, что с помощью этого метода можно предсказать, сколько времени понадобится пользователю на его задачи с абсолютной погрешностью менее 5%.
Также, не стоит считать, что этим методом мы измерили конкретное время работы с интерфейсом. Это странно, ведь, по сути мы именно это и сделали, но надо понимать, что секунды использованы больше как некая условность. Ведь, у разных юзеров может быть разная скорость работы. Просто нам нужно было понять насколько конкретно один интерфейс юзабельней другого и единицы измерения нам в этом помогли. Реальная скорость работы может совпадать с нашими ожиданиями, а может и не совпадать всё будет зависеть от конкретного юзера.
Моё мнение о GOMS анализе
Когда я только узнал о нём мне захотелось немедленно начать его использовать во всех своих проектах. Мне казалось, что вот оно избавление от извечных мук выбора как правильней. Без субъективщины и трендов. Реальная тупая математика. Но на деле, чтобы описать даже самый примитивный интерфейс, надо потратить раза в два больше времени чем на его проектирование. А потом всё равно придётся спроектировать альтернативный вариант чтобы посчитать и его. И даже если в итоге я узнаю какой вариант лучше, окажется, что он лучше на 0,65 сек. Потратить 34 часа чтобы выиграть 0,65 сек это мощно.
Тем не менее я, считаю, что метод всё равно классный и его стоит использовать, но в каких-то супер важных интерфейсах в которых даже 0,65 сек имеют значение. В большинстве же проектов логичней положиться на свой опыт и постфактум просто спросить юзеров, как им удобнее.
Раскин примерно так и пишет:
Разработчики, которые знакомы с методом GOMS, редко проводят детальный и формальный анализ модели интерфейса. Отчасти это происходит из-за того, что основы GOMS и других количественных методов известны им настолько, что они изначально руководствуются этими методами в процессе разработки.
P. S.
Существуют и модификации GOMS анализа. Например, Сritical-path method GOMS (CPM-GOMS) и версия, называемая естественным языком GOMS (natural GOMS language, NGOMSL) в которой учитывается поведение неопытного пользователя, например время, необходимое ему для обучения. Об этих версиях вы можете прочитать самостоятельно.
