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

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

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

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

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

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

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

Многие из этих традиций рассматриваются в главах 5 и 10.

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

Генри Спенсер.

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

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

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

Глава 25. Когда не следует использовать ХР

Из книги Экстремальное программирование автора Бек Кент

Глава 25. Когда не следует использовать ХР Точные пределы использования ХР еще не до конца исследованы. Однако есть известный набор факторов, который делает применение ХР невозможным, – слишком большие команды, недоверчивые заказчики, технология, которая не позволяет


1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

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

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск


1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

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

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


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

Из книги Основы объектно-ориентированного программирования автора Мейер Бертран

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


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

Из книги Стандарты программирования на С++. 101 правило и рекомендация автора Александреску Андрей

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


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

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

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных


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

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

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


19.4. Почему следует использовать стандартную лицензию

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

19.4. Почему следует использовать стандартную лицензию Широко известные лицензии, которые согласуются с Определением открытого исходного кода (Open Source Definition), имеют твердо установившиеся "толковательные" традиции. Разработчики (и пользователи, в той мере, как это их


1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

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

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск


1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

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

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


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

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

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

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

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных


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

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

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


19.4. Почему следует использовать стандартную лицензию

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

19.4. Почему следует использовать стандартную лицензию Широко известные лицензии, которые согласуются с Определением открытого исходного кода (Open Source Definition), имеют твердо установившиеся "толковательные" традиции. Разработчики (и пользователи, в той мере, как это их


Что следует повторно использовать?

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

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


72. Для уведомления об ошибках следует использовать исключения

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

72. Для уведомления об ошибках следует использовать исключения РезюмеДля уведомления об ошибках лучше использовать механизм исключений, а не коды ошибок. Применять коды состояния (например, коды ошибок, переменную errno) следует только тогда, когда нельзя использовать