Зачем читать книгу?

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

Чем крут автор?

Обаятельный бородач Джеф Раскин более 30 лет занимался интерфейсами. Трудился в Apple Computer и был инициатором разработки Macintosh. В 1987-м выпустил свой настольный компьютер Canon Cat. Довольно революционная для своего времени железяка. Ну, со слов нескромного Раскина… По ходу повествования автор тщательно подбирает аргументы и с упоением подкрепляет выводы многочисленными научными исследованиями.

Ключевые мысли из книги своими словами

Без лишних слов, сразу сформулируем кратко законы Раскина:

1. Обеспечь сохранность данных пользователя.

2. Не вынуждай его производить лишние действия.

3. Дай пользователю возможность самому установить ритм взаимодействия (не заставляй ждать, но и не подгоняй).

Когнитивные ограничения

Что это вообще такое? Также как эргономика описывает физические ограничения человека, когнетика занимается изучением ограничений мышления.

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

Сила привычки

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

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

Жесты и режимы

Жест (в рамках данной книги) — это набор автоматических действий пользователя.

Режим (опять же в текущем контексте) —состояние интерфейса при котором только что осуществленный жест интерпретируется по прежнему.

С режимами связана определенная сложность. Иногда бывает трудно правильно назвать ту или иную кнопку. Решение — максимально понятно отображать текущий режим и информировать пользователя, если жест приведет к смене режима.

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

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

Ошибочные выводы

Раскин указывает на две типичные ошибки новичков-проектировщиков:

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

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

Квазирежимы

Этим странным словом Раскин называет режим, удерживаемый пользователем кинестетически.

Хороший пример — нажатие на педаль или появляющийся список подразделов меню при нажатии на заголовок корневого раздела.

Существительное ↔ глагол

Команды используются во всех интерфейсах, и автор задается вопросом: в какой последовательности должны следовать слова, а точнее выполняться действия. Правильный порядок: сначала выбрать объект, а затем определить действие, применяемое к нему. Т.е. сначала существительное, затем — глагол.

Почему именно так? Это позволит не запоминать, какое действие было выбрано вначале. Не придется переключать внимание, а манипуляции будут простыми и обратимыми.

Мастерство анализа интерфейса

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

В переводе аббревиатура означает «правила для целей, объектов, методов и выделения». Суть модели заключается в том, что можно просчитать оптимальное время выполнения задачи, а затем сравнить его с временем, реально затрачиваемым пользователем. Если разница между показателями будет слишком велика — интерфейс плох и непонятен.

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

В книге приводятся наглядные примеры и рассказывается о способах вычисления среднего количества информации, вводимого в то или иное поле.

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

Фиттс и Хик

Раскин приводит несколько законов (читай: сложных формул), на основании которых следует проектировать интерфейсы.

Постараюсь описать приведенное в книге кратко и без математических символов:

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

Закон Хика разъясняет еще одну очевидность: чем меньше элементов предоставлено на выбор, тем быстрее этот самый выбор будет сделан.

Набор возможностей

Разрабатывая интерфейс всегда нужно помнить о наборе простых действий пользователя:

• указание,

• выделение,

• активация,

• модификация,

• генерация,

• удаление,

• перемещение,

• трансформация в другой тип данных,

• копирование.

Именно на этих комбинациях построено любое взаимодействие с интерфейсом.

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

Лишние проблемы интерфейса

Несколько важных штук, которыми не следует пренебрегать:

• Бесполезные сокращения. Лаконичность в обозначении элемента хороша не всегда. Гораздо важнее сразу донести смысл, чем сэкономить место.

• Неуместные пиктограммы. Если иконка нуждается в подписи и разъяснении, то лучше сразу заменить её текстом.

• Не простота, а понятность. Если интерфейс уже не возможно упростить, но он все еще не понятен пользователю, стоит оставлять инструкции. Не нужно сразу вываливать на юзера весь «мануал по использованию». Лучше просто делать уместные и понятные подсказки по ходу взаимодействия в нужных местах.

• Безопасное удаление. Имея дело с интерфейсами, где предусмотрены действия «удалить» или «вырезать», пользователь должен быть уверен, что он случайно не произведет необратимого действия. Всегда должна существовать возможность отмены или альтернативный вариант хранения удаляемых данных.

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

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

• Простой вход. Вход в закрытую часть интерфейса нужно делать простым. Чаще всего достаточно использования пароля без логина. Также допустимы другие быстрые варианты: голосовая команда и пр.

Проблемы вне системы

В книге автор также говорит не только об конкретных проектировочных решениях, но и о более глобальных штуках.

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

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

Два ключевых действия

Раскин постоянно повторяет, что нужно стремиться делать интерфейсы как можно более простыми. Для этого он советует выполнять два простых действия:

1. Определить возможности и ограничения;

2. Проследить мысленную цепочку умозаключений, которые будущий пользователь сформирует при взаимодействии с интерфейсом.

«Наши способности разделяются между когнитивным сознательным и когнитивным бессознательным. Мы обладаем только одним локусом внимания, а наши привычки играют главную роль в работе с интерфейсами», — заключает автор.

Удалось осилить эту заметку? Вы сэкономили не только кучу времени, но и уберегли себя от постоянных повторений одной и той же мысли, встречающихся в американском нонфикшене (:

В блоге, кстати, есть другие краткие содержания книжек

А больше интересностей о юиксе в жизни — в моей телеге