В дизайне пользовательского интерфейса и программном обеспечении [1] принцип наименьшего удивления ( POLA ), также известный как принцип наименьшего удивления , [a] предполагает, что компонент системы должен вести себя так, как большинство пользователей ожидают от него, и, следовательно, не удивлять и не удивлять пользователей. Следующее является следствием принципа: «Если необходимая функция имеет высокий фактор удивления, может потребоваться перепроектировать функцию». [4]
Этот принцип используется в отношении компьютерного взаимодействия по крайней мере с 1970-х годов. Хотя он впервые был формализован в области компьютерных технологий, этот принцип может широко применяться и в других областях. Например, в письменной форме перекрестная ссылка на другую часть работы или гиперссылка должны быть сформулированы таким образом, чтобы точно сообщать читателю, чего ожидать.
Ранняя ссылка на «Закон наименьшего удивления» появилась в бюллетене PL/I в 1967 году (PL/I — язык программирования, выпущенный IBM в 1966 году). [5] К концу 1960-х годов PL/I стал печально известен нарушением закона, [6] например, из-за правил преобразования точности PL/I, [7] выражения 25 + 1/3и 1/3 + 25либо приводили к фатальной ошибке, либо, если ошибки подавлялись, 5.33333333333 вместо правильных 25.33333333333. [8]
Закон был полностью изложен в 1972 году:
Для тех частей системы, которые не могут быть адаптированы к особенностям пользователя, разработчики языка системного программирования должны следовать «Закону наименьшего удивления». Короче говоря, этот закон гласит, что каждая конструкция в системе должна вести себя точно так, как предполагает ее синтаксис. Широко принятые соглашения должны соблюдаться, когда это возможно, а исключения из ранее установленных правил языка должны быть минимальными. [9]
Формулировка из учебника такова: «Люди являются частью системы. Дизайн должен соответствовать опыту пользователя, его ожиданиям и ментальным моделям ». [10]
Принцип направлен на использование существующих знаний пользователей для минимизации кривой обучения , например, путем разработки интерфейсов, которые в значительной степени заимствуют из «функционально схожих или аналогичных программ, с которыми ваши пользователи, вероятно, знакомы». [2] Ожидания пользователей в этом отношении могут быть тесно связаны с конкретной вычислительной платформой или традицией . Например, ожидается, что программы командной строки Unix будут следовать определенным соглашениям в отношении переключателей , [2] а виджеты программ Microsoft Windows должны следовать определенным соглашениям в отношении сочетаний клавиш . [11] В более абстрактных настройках, таких как API , ожидание того, что имена функций или методов интуитивно соответствуют их поведению, является еще одним примером. [12] Эта практика также включает применение разумных значений по умолчанию . [4]
Когда два элемента интерфейса конфликтуют или неоднозначны, поведение должно быть таким, которое меньше всего удивит пользователя ; в частности, программист должен попытаться придумать такое поведение, которое меньше всего удивит того, кто использует программу, а не такое поведение, которое является естественным, исходя из знания внутренней работы программы. [4]
Выбор «наименее удивительного» поведения может зависеть от ожидаемой аудитории (например, конечные пользователи , программисты или системные администраторы ). [2]
Веб-сайты, предлагающие сочетания клавиш, часто позволяют нажатием ?увидеть доступные сочетания клавиш. Примерами являются Gmail , [13] YouTube , [14] и Jira . [15]
В операционных системах Windows и некоторых средах рабочего стола для Linux функциональная клавиша обычно открывает справочную программу для приложения . Аналогичное сочетание клавиш в macOS — + + . Пользователи ожидают появления окна справки или контекстного меню при нажатии обычной клавиши(ок) справки. Программное обеспечение, которое вместо этого использует эту комбинацию клавиш для другой функции, скорее всего, вызовет удивление, если справка не появится. [16]F1 ⌘ Command⇧ Shift/
Стандартная библиотека языка программирования обычно предоставляет функцию , похожую на псевдокод , которая создает машиночитаемое целое число из строки цифр , читаемых человеком . Система счисления по умолчанию обычно равна 10, что означает, что строка интерпретируется как десятичная (основание 10). Эта функция обычно поддерживает другие основания, такие как двоичное (основание 2) и восьмеричное (основание 8), но только когда они указаны явно. В отходе от этого соглашения JavaScript изначально использовал основание 8 для строк, начинающихся с «0», что вызывало путаницу у разработчиков и ошибки программного обеспечения . [17] Это не поощрялось в ECMAScript 3 и было исключено в ECMAScript 5. [18] ParseInteger(string, radix)
Некоторые сообщества разработчиков, такие как FreeBSD [19], используют POLA в качестве одного из руководящих принципов того, что делает пользовательский опыт не вызывающим удивления.
Может ли быть высокий фактор удивления, связанный с новой функцией? Если функция случайно неправильно применена пользователем и вызывает то, что кажется ему непредсказуемым результатом, эта функция имеет высокий фактор удивления и, следовательно, нежелательна. Если необходимая функция имеет высокий фактор удивления, может потребоваться перепроектировать функцию.
Как однажды заметил мне один мой друг — это было, должно быть, где-то в конце 1960-х годов — что бы вы ни говорили о нем, есть одна вещь, которой PL/I определенно не является, а именно, «язык наименьшего удивления».
PL/I является здесь главным плохим примером; он усеян конструкциями, которые не делают то, что думает программист, как показано на примере ФИКСИРОВАННОГО деления.
к сожалению, выражение «25 + 1/3» дает 5.3333333333333
Чтобы программист, не использующий PL/I, не пришел к ошибочному выводу, что PL/I не имеет недостатков, рассмотрим следующие примеры враждебности PL/I. Правил преобразования типов в PL/I достаточно, чтобы вызвать язвы у программистов. Какой еще язык мог бы выдать фатальную ошибку при оценке выражения (25 + 1/3)? (Так же плохо, если вы подавите проверку ошибок, результатом оценки выражения будет 5.3333...)
PL/I печально известен в этом отношении, так как он преобразует почти любой тип в любой другой тип, иногда с удивительными результатами. Рассмотрим выражение 1/3 + 25. В PL/I это выражение имеет значение 5.33333333333. Почему? Одна треть вычисляется с точностью до 15 цифр, 14 справа от десятичной точки. Затем 25 приводится к той же точности, теряя самую значимую цифру 2! Это действительно вызывает ошибку в PL/I, но по умолчанию она игнорируется. Впервые это появилось в печати в Barron 1968, где это указано как нарушение народного закона проектирования языка: «закона наименьшего удивления».
Рассмотрим следующее выражение: 25+1/3. Результат оценки этого выражения не определен, и возникает условие FIXEDOVERFLOW, поскольку деление FIXED приводит к значению максимальной точности, определенной реализацией. [...] Результаты двух оценок достигаются, как показано в Таблице 29.
Если входная строка начинается с "0" (нуля), предполагается, что основание системы счисления равно 8 (восьмеричное) или 10 (десятичное). Какой именно выбор основания зависит от реализации. ECMAScript 5 разъясняет, что следует использовать 10 (десятичное), но пока не все браузеры поддерживают это.