11.1. Применение правила наименьшей неожиданности

11.1. Применение правила наименьшей неожиданности

Правило наименьшей неожиданности представляет собой общий принцип проектирования всех видов интерфейсов, а не только программных: "делайте наименее неожиданные вещи". Данное правило — следствие того факта, что человек способен уделять внимание одновременно только одному объекту (см. книгу "The Humane Interface" [64]). Неожиданности в интерфейсе притягивают внимание к самому интерфейсу, а не к задаче, для решения которой он предназначен.

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

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

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

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

В случае, когда делегирование невозможно, следует воспроизводить удачные решения. Целью правила наименьшей неожиданности является сокращение общей сложности, которую необходимо постичь пользователю, для того чтобы использовать интерфейс. Относительно примера с текстовым редактором, это означает, что если реализовать встроенный редактор действительно необходимо, то будет лучше, если команды этого редактора будут представлять собой подмножество команд широко известного универсального редактора (или нескольких редакторов; в оболочках bash и ksh имеются CLI-редакторы, которые позволяют пользователям выбирать стиль редактирования vi или Emacs.)

Например, в Unix-версиях Web-браузеров Netscape и Mozilla текстовые поля форм распознают подмножество стандартных клавиатурных комбинаций для редактора Emacs. Control-A переводит курсор в начало строки, Control-D удаляет следующий символ и так далее. Такой вариант помогает пользователям, знакомым с Emacs, а остальным позволяет использовать не худший, уникальный набор команд. Единственным способом улучшить его был выбор клавиатурных комбинаций, связанных с каким-либо редактором, получившим более широкое распространение, чем Emacs. Но среди первых пользователей Netscape такой редактор не использовался.

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

1.5. Правила

Из книги Программирование на языке Пролог автора Клоксин У.

1.5. Правила Предположим, мы хотим сформулировать утверждение, что Джону нравятся все люди. Один из способов сделать это заключается в записи для каждого человека, упоминаемого в базе данных, отдельного факта:нравится(джон,альфред). нравится(джон,бертран).


2.1. Синтаксические правила

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

2.1. Синтаксические правила Синтаксические правила языка описывают допустимые способы соединения слов. В соответствии с нормами английского языка предложение «I see a zebra» («я вижу зебру») является синтаксически правильным в отличие от предложения «zebra see I а» («зебра видит


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании


11.1. Применение правила наименьшей неожиданности

Из книги Справочник по CSS автора Коллектив авторов

11.1. Применение правила наименьшей неожиданности Правило наименьшей неожиданности представляет собой общий принцип проектирования всех видов интерфейсов, а не только программных: "делайте наименее неожиданные вещи". Данное правило — следствие того факта, что человек


15.4.3. Правила make

Из книги Ководство автора Лебедев Артём Андреевич

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


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги Разработка приложений в среде Linux. Второе издание автора Джонсон Майкл К.

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании являются


15.4.3. Правила make

Из книги Интернет – легко и просто! автора Александров Егор

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


Правила

Из книги Быстрые деньги в Интернете [50 способов заработать, сидя дома у компьютера] автора Парабеллум Андрей Алексеевич

Правила Правила используются в таблицах стилей для особых нужд.charsetЗадает текстовую кодировку для внешней таблицы стилей.@charset {Кодировка};Пример:@charset "windows-1251";Может использоваться только во внешних таблицах стилей; должна быть первой строкой в файле. Поддерживается IE


§ 165. Три правила про вы

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

§ 165. Три правила про вы 7 сентября 2010В русском языке существует местоимение вы, к которому прилагаются довольно простые правила употребления и неупотребления.Вы всегда пишется с маленькойСовершенно невыносима рекламно-подобострастная манера писать Вы с заглавной


4.2.3. Суффиксные правила

Из книги Linux глазами хакера автора Флёнов Михаил Евгеньевич

4.2.3. Суффиксные правила Суффиксные правила — это другая область, в которой вам нужно решить, писать ли стандартные make-файлы или использовать расширения GNU. Стандартные суффиксные правила намного ограниченнее, нежели шаблонные правила GNU, но во многих ситуациях


Правила для сообщений

Из книги HTML, XHTML и CSS на 100% автора Квинт Игорь

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


19.6.5. Правила фильтрации

Из книги автора

19.6.5. Правила фильтрации Задание правил фильтрации IPTables похоже на задание правил в IPChains. Для создания правила используется опция --append (или -А). После этой опции указывается имя цепочки и критерий выбора пакетов в этой цепочке. Затем указывается опция --jump (или -j), значением


4.1.3. Правила безопасности

Из книги автора

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


4.11.4. Правила "все кроме"

Из книги автора

4.11.4. Правила "все кроме" Очень часто приходится задавать правила в виде "все кроме". Например, нужно запретить доступ к порту telnet всем пользователям, кроме компьютера с адресом 192.168.77.10. Лучше поступить следующим образом: сначала разрешить доступ для компьютера 192.168.77.10, а


Правила@

Из книги автора

Правила@ Правила @ начинаются с ключевого слова @, непосредственно за которым следует идентификатор (например, @import, @page). Каждый из этих идентификаторов далее рассмотрим подробнее.Все же надо отметить, что браузер с поддержкой CSS будет игнорировать все правила @import, которые