Рекомендации по проектированию пользовательских интерфейсов (по книге Раскина «Интерфейс»). Часть 1

    Материал, который я собираюсь изложить — это обобщение книги Джефа Раскина, дополненное некоторыми рассуждениями на основе собственного опыта. Первый пост в этой серии — «Вступление» — находится здесь.
    В первой части описаны особенности человеческого восприятия, важные для проектирования интерфейса, а также принципы построения интерфейса.

    1. Особенности человеческого восприятия


    1.1. Локус внимания

    В любой момент времени человек может сосредоточить свое внимание только на одном предмете. Это может быть какой-то объект реального мира (например, лист бумаги) определенная область экрана или окна, а может и какой-нибудь процесс «в уме» (например, когда человек обдумывает свои действия или что-то рассчитывает). Предмет, на котором сосредоточено внимание человека, будем называть локусом его внимания. С локусом внимания связано как минимум две особенности человеческого восприятия.

    1. При периодическом переключении внимания, например, с рабочей области документа на уведомления об ошибках, эффективность работы снижается. Это связано с тем, что при смене локуса теряется связанная с ним «оперативная» информация, которая содержится в кратковременной памяти. Соответственно, при возвращении к прежнему локусу эту информацию необходимо каким-то образом восстанавливать.

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

    1.2. Формирование привычек

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

    Привычка может оказаться и вредной. Типичный пример — подтверждение выполнения команды в диалоговом окне. Если диалоговое окно возникает каждый раз при выполнении рутинных операций, то в конце концов человек перестает читать текст в этом окне (и это справедливо не только для таких «классических» пользователей как бухгалтеры или секретарши, но и для самих программистов). Поэтому если похожее окно возникнет, когда пользователь отдал команду по ошибке, то он, не задумываясь, подтвердит команду, потому что это вошло у него в привычку. Это может иметь печальные последствия, если команда была необратимой и привела к уничтожению важных данных. Хочу подчеркнуть, что приведенный пример вреда от привычки является проблемой не пользователя, а самого интерфейса. Одним из способов избежать подобных проблем является обеспечение обратимости команд везде, где это только возможно.

    1.3. Промлема модальности

    Существенным препятствием для формирования у пользователя привычек при работе с интерфейсом является наличие в интерфейсе нескольких режимов. Режимы — это состояния интерфейса, в которых один и тот же жест пользователя интерпретируется по-разному. Жестом может являться набор слова, нажатия определенного сочетания клавиш (например, Ctrl-S) или кнопки мыши, даже движение мышью и т.п. Модальность является также серьезным источником ошибок при взаимодействии с программой. Даже изменение состояния объекта (например, с включенного на отключенное), выполняемое одним и тем же жестом, является модальным, поскольку для выполнения желаемого действия («включить», «отключить») необходимо знать и держать в локусе внимания текущее состояние объекта. Как было сказано в подразделе 1.1, если внимание человека сосредоточено на чем-то другом, то информация о состояниянии объекта может быть проигнорирована, что повлечет за собой ошибки.

    К счастью, модальности интерфейса не возникает в двух случаях.

    1. В случае, если контекст, в котором выполняется жест, находится в локусе внимания пользователя. Например, нажатие клавиши Backspace при наборе текста можно было бы считать модальным, поскольку результат этого жеста зависит от того, какая буква находится перед курсором. Однако, данная буква находится в локусе внимания, поскольку именно ее пользователь хочет удалить при нажатии Backspace. Клавиша Caps Lock, напротив, во многих случаях является модальной, т.к. сохраняет свой эффект — изменение регистра букв — и после того, как локус внимания пользователя сместился с набора нужного слова в верхнем регистре на другие операции.

    2. Если при выполнении жеста дополнительно удерживается какая-либо клавиша или несколько (например, Ctrl или Ctrl + Alt). Фактически, такой жест воспринимается как новый, поэтому не конфликтует с другими. Раскин называет подобную модификацию «квазирежимом».

    2. Принципы построения интерфейсов


    2.1. Отсутствие модальности

    Поскольку модальность приводит к ошибкам взаимодействия с программой, хорошим принципом создания интерфейсов является исключение модальности. Один из способов достичь этого — использование «квазирежимов» (см. также подраздел 1.3).

    2.2. Сохранность пользовательских данных

    Назначением большинства программ в конечном итоге является (должно являться) упрощение работы, выполняемой человеком. Пользовательские данные — это результат работы человека. Если этот результат будет утерян, работу придется выполнять снова, что нельзя назвать упрощением. Поэтому любая программа должна обеспечивать сохранность данных пользователя, будь то простое текстовое сообщение, 3D-модель или научная статья. О важности данных может судить только сам пользователь, но никак не программа, с которой он взаимодействует. Путей для обеспечения сохранности данных может быть много: это и автоматическое сохранение любых изменений, и обратимость операций, и создание резервного архива (backup).

    2.3. Формирование команд по принципу «объект -> действие»

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

    1. Сначала указать объект, а затем действие, которое необходимо совершить с этим объектом (модель «объект-действие»).

    2. Сначала указать действие, а затем объект, к которому следует применить это действие (модель «действие-объект»).
    Предпочтительной является первая модель — «объект-действие». Во-первых, она исключает многие модальные ошибки, поскольку переключение действия обычно сопровождается переключением режимов работы. Во-вторых, она проще для восприятия человеком, поскольку, как правило, локус внимания пользователя уже находится на объекте, когда возникает необходимость выполнить какое-то действие с этим объектом.
    Использование второй модели — «действие-объект» — тоже допустимо, но только в тех случаях, когда ее применение достаточно аргументировано.

    2.4. Монотонность

    Привычки могут формироваться у человека лишь в том случае, если каждое действие можно выполнить всегда одним и тем же образом. Интерфейс можно назвать монотонным, когда каждое элементарное действие в нем можно выполнить ровно одним способом (т.е. жестом). Часто для одного и того же действия предусматривается несколько способов выполнения: через меню, сочетанием клавиш, щелчком мыши и т.п. Однако подобная практика затрудняет формирование привычек, поскольку пользователь должен каждый раз выбирать, каким способом выполнить действие. И лишь когда он станет выполнять действие всегда только одним способом, т.е. сам сведет немонотонный интерфейс к монотонному, у него появится возможность формировать привычку для выполнения этого действия. Если сразу спроектировать интерфейс так, чтобы он был монотонным, то это сократит время обучения пользователя. Исключение, вероятно, может составлять случай, когда проектируется интерфейс для пользователей с разными устройствами. Например, часть пользователей пользуется настольным ПК с клавиатурой и мышью, а часть — планшетным ПК с сенсорным экраном. Однако и в этом случае стоит подумать о других альтернативах, например, нахождении способа взаимодействия, который будет применим на разных устройствах, или разработке разных версий интерфейса для разных устройств. Иначе есть риск создать интерфейс, который не будет устраивать ни ту, ни другую группу пользователей.

    2.5. Видимость

    Интерфейс программы должен своевременно информировать пользователя о:
    1) текущем состоянии системы и смене состояния в результате действий пользователя;
    2) способах управления и воздействия на систему.

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

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

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

    2.6. Состоятельность

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

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

    Similar posts

    Comments 13

      +7
      скучно читать про проектирование интерфейсов без картинок
        0
        спасибо, постараюсь учесть Ваше пожелание при написании следующих частей
        +1
        Нужно все-таки показывать удачные примеры и не удачные.
        Вот так плохо… вот так хорошо.
          0
          да, пожалуй, стоило бы. проблема в том, что тогда текст раздулся бы еще больше, а я хотел по возможности кратко изложить основные идеи из книги. думаю, это может стать темой для отдельного поста, или даже нескольких
            +1
            Да не… Хабр не боится объема или трафика. Хабр боится непонятности :)
          0
          Боже! Вам же в предыдущий раз намекнули про оформление. Вы конечно же подумали, что все дело исключительно в неправильных картинках.

          Я вам по секрету расскажу, что, на самом деле, нужно исправить в статье (дальше шёпотом): добавьте пустую строку после каждого абзаца.
            0
            добавил. теперь читать стало легче?
            +2
            Вы взяли на себя очень интересную и полезную задачу. Приведённые рекомендации очень полезны. Я надеюсь на продолжение публикаций.

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

            К примеру, рассмотрим предложение:
            Монотонностью называется однозначность соответствия
            жеста действию, которое он выполняет.

            Вполне можно сказать:
            Интерфейс считается предсказуемым, если одни и те же действия приводят к одним и тем же результатам.
              0
              да, со стилем у меня проблемы бывают, хоть я и стараюсь писать проще.
              что касается монотонности, то это, похоже, пример того, что я сложно (или неточно?) написал, т.к. Вы не совсем правильно поняли.
              я хотел сказать, что есть такое свойство интерфейса, как монотонность. это когда каждое действие можно выполнить ровно одним способом (т.е. жестом).
              поправлю этот момент в тексте, спасибо
                +1
                Прошу прощения, что неправильно Вас понял. Однако, рад, что Вы поняли, что я Вас неправильно понял и, похоже, поняли почему это непонимание произошло.
              0
              Материал хороший, но часто мой мозг отказывается воспринимать текст.Вам предстоит пройти тот-же путь в написании статей, что и в написании программ — сухая подача информации не может донести до пользователя суть.

              Присоединяюсь к вышесказанному, картинки необходимы. Многие статьи по UI базируются на примерах в виде картинок, а поясняющий текст содержит не более 3 строк и в большинстве случаев не обязателен к прочтению.

              То же самое с заголовками. К примеру, можно заменить «Видимость» на «Покажите пользователю необходимую информацию»
                0
                Многие статьи по UI базируются на примерах в виде картинок, а поясняющий текст содержит не более 3 строк и в большинстве случаев не обязателен к прочтению.


                Проблема многих статей по UI в том, что им не хватает систематичности: часто они предлагают набор эмпирических правил, особо друг с другом не связанных, и основываются на каких-то общих соображениях. преимущество подхода Раскина как раз в систематичности — он дает хороший базис, на основании которого далее можно рассуждать о необходимости той или иной «фичи» в интерфейсе. картинки все-таки нужно было вставить для облегчения восприятия, признаю. но и некоторый объем текста тут тоже важен, чтобы разъяснить этот базис.
                0
                Отличный конспект. Спасибо за проделанную работу!
                Если добавить иллюстрации, то можно использовать в качестве пособия.

                Only users with full accounts can post comments. Log in, please.