[Usability, Веб-дизайн, Интерфейсы] GOMS-анализ юзабилити интерфейса
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Данная статья практически полностью основана на цитатах из книги Джефа Раскина «Интерфейс — новые направления в проектировании компьютерных систем» с моими дополнениями и воссозданием приводимого в книге примера интерфейса.
Быстрый ответ на вопрос стоит ли использовать 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 сек. Потратить 3—4 часа чтобы выиграть 0,65 сек — это мощно.
Тем не менее я, считаю, что метод всё равно классный и его стоит использовать, но в каких-то супер важных интерфейсах в которых даже 0,65 сек имеют значение. В большинстве же проектов логичней положиться на свой опыт и постфактум просто спросить юзеров, как им удобнее.
Раскин примерно так и пишет:
«Разработчики, которые знакомы с методом GOMS, редко проводят детальный и формальный анализ модели интерфейса. Отчасти это происходит из-за того, что основы GOMS и других количественных методов известны им настолько, что они изначально руководствуются этими методами в процессе разработки.»
P. S.
Существуют и модификации GOMS анализа. Например, «Сritical-path method GOMS» (CPM-GOMS) и версия, называемая естественным языком GOMS (natural GOMS language, NGOMSL) в которой учитывается поведение неопытного пользователя, например время, необходимое ему для обучения. Об этих версиях вы можете прочитать самостоятельно.
===========
Источник:
habr.com
===========
Похожие новости:
- [CAD/CAM, IT-компании] 118 обучающих уроков для проектировщиков. Как это было
- [Гаджеты, Интерфейсы, История IT, Софт, Старое железо] Windows Tablet PC — 10 лет прогресса
- [Веб-дизайн, Разработка веб-сайтов] Один в поле не воин или как бэкендер фулстеком попытался стать
- [Big Data] Цифровые двойники: почему все о них говорят и всем ли они нужны?
- [Машинное обучение, Мозг, Научно-популярное] Интерфейсы «мозг — компьютер» в образовании
- [Биотехнологии, Здоровье, Научно-популярное, Химия] Хлопковая нить, биолюминесценция и смартфон: анализ крови на антитела за 5 минут
- [Веб-дизайн, Дизайн, Разработка веб-сайтов, Финансы в IT] Как выделиться с помощью сайта? Дизайн с ощущением левитации
- [GitHub, Python, Алгоритмы, Веб-аналитика] Как проанализировать рынок фотостудий с помощью Python (1/3). Парсинг данных
- [Big Data, Data Mining, Визуализация данных, Открытые данные] Аномалии общероссийского голосования по поправкам к Конституции России. Часть 1
- [Growth Hacking, Бизнес-модели, Развитие стартапа] История Airbnb: Какие уроки можно из нее извлечь?
Теги для поиска: #_usability, #_vebdizajn (Веб-дизайн), #_interfejsy (Интерфейсы), #_raskin (раскин), #_interfejsy (интерфейсы), #_analiz (анализ), #_urok (урок), #_usability, #_vebdizajn (
Веб-дизайн
), #_interfejsy (
Интерфейсы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Данная статья практически полностью основана на цитатах из книги Джефа Раскина «Интерфейс — новые направления в проектировании компьютерных систем» с моими дополнениями и воссозданием приводимого в книге примера интерфейса. Быстрый ответ на вопрос стоит ли использовать GOMS-анализ для проверки юзабилити: «Если вы проектируете интерфейс, при работе с которым от задержки в 0,3 сек. никто не умирает — не стоит.». Итак, «The model of Goals, Objects, Methods, and Selection rules» (GOMS) — это метод исследования интерфейса, разработанный Кардом, Мораном и Ньюэллом в 80-х годах. GOMS позволяет предсказать, сколько времени потребуется опытному (именно опытному) пользователю на выполнение конкретной операции при использовании конкретного интерфейса. Теперь, когда мы привыкли к этому странному для русского уха термину, можно описать его суть. Разработчики GOMS заметили, что время на выполнение какой-то задачи пользователем, равно сумме всех временных интервалов, которые потребовались на выполнение каждого конкретного жеста пользователя (например, переместить руку с мыши на клавиатуру и набрать букву). С помощью лабораторных исследований был получен набор временных интервалов, требуемых для выполнения различных жестов. Жесты и время по модели GOMS:
В дальнейших расчётах Жесты будут заменяться буквенными обозначениями из списка выше и будут называться «Операторы». Ниже пойдут довольно замысловатые правила работы с этими самыми жестами (операторами). Пока просто прочитайте их, а дальше я всё объясню на примере. Правила расстановки операторов:
Применение метода Дано: Юзера просят перевести температуру из Фаренгейта в Цельсий или наоборот. Например, могут попросить: «Переведи, 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 сек. Потратить 3—4 часа чтобы выиграть 0,65 сек — это мощно. Тем не менее я, считаю, что метод всё равно классный и его стоит использовать, но в каких-то супер важных интерфейсах в которых даже 0,65 сек имеют значение. В большинстве же проектов логичней положиться на свой опыт и постфактум просто спросить юзеров, как им удобнее. Раскин примерно так и пишет: «Разработчики, которые знакомы с методом GOMS, редко проводят детальный и формальный анализ модели интерфейса. Отчасти это происходит из-за того, что основы GOMS и других количественных методов известны им настолько, что они изначально руководствуются этими методами в процессе разработки.»
P. S. Существуют и модификации GOMS анализа. Например, «Сritical-path method GOMS» (CPM-GOMS) и версия, называемая естественным языком GOMS (natural GOMS language, NGOMSL) в которой учитывается поведение неопытного пользователя, например время, необходимое ему для обучения. Об этих версиях вы можете прочитать самостоятельно. =========== Источник: habr.com =========== Похожие новости:
Веб-дизайн ), #_interfejsy ( Интерфейсы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:29
Часовой пояс: UTC + 5