Принцип наименьшего удивления

В проектировании пользовательского интерфейса и разработке программного обеспечения ^[1] принцип наименьшего удивления ( POLA ), также известный как принцип наименьшего удивления , ^[а] предполагает, что компонент системы должен вести себя так, как ожидает от него большинство пользователей, и, следовательно, не удивлять и не удивлять пользователей. Следующее является следствием этого принципа: «Если необходимая функция имеет высокий фактор удивления, может потребоваться ее перепроектирование». ^[4]

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

Источник

Первая ссылка на «Закон наименьшего удивления» появилась в бюллетене PL/I в 1967 году (PL/I — язык программирования, выпущенный IBM в 1966 году). ^[5] К концу 1960-х годов ЛП/И прославилась нарушением закона. ^[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] Ютуб , ^[14] и Джира . ^[15]

В операционных системах Windows некоторых средах рабочего стола для Linux и F1 Функциональная клавиша обычно открывает справочную программу для приложения . Аналогичное сочетание клавиш в macOS : ⌘ Command+ ⇧ Shift+ /. справки Пользователи ожидают появления окна или контекстного меню при нажатии обычных клавиш быстрого доступа к справке. Программное обеспечение, которое вместо этого использует этот ярлык для другой функции, скорее всего, вызовет удивление, если не появится помощь. ^[16]

Стандартная программирования языка библиотека обычно предоставляет функцию, аналогичную псевдокоду. ParseInteger(string, radix), который создает машиночитаемое целое число из строки человекочитаемых цифр . система счисления Обычно по умолчанию равна 10, что означает, что строка интерпретируется как десятичная (основание 10). Эта функция обычно поддерживает другие системы счисления, например двоичную (базовая 2) и восьмеричную (базовую 8), но только если они указаны явно. В отличие от этого соглашения, в JavaScript изначально по умолчанию использовалось основание 8 для строк, начинающихся с «0», что приводило к путанице разработчиков и ошибкам программного обеспечения . ^[17] Это не поощрялось в ECMAScript 3 и было исключено в ECMAScript 5. ^[18]

Некоторые сообщества разработчиков, такие как FreeBSD ^[19] используйте POLA в качестве одного из принципов того, что делает пользовательский опыт неудивительным.

См. также

Примечания

^ Альтернативно закон наименьшего сюрприза или правило наименьшего сюрприза . ^[2]^[3]

Ссылки

^ Зеебах, Питер (1 августа 2001 г.). «Принцип наименьшего удивления» . Капризный пользователь . IBM DeveloperWorks . Проверено 23 января 2014 г.
^ Jump up to: ^а ^б ^с ^д Раймонд, Эрик Стивен (2003). «Применение правила наименьшего сюрприза». Искусство программирования для Unix . faqs.org. п. 20. ISBN 978-0-13-142901-7 . Проверено 23 августа 2020 г.
^ Джеймс, Джеффри (1987). Дао программирования . Информационные книги. 4.1. ISBN 0-931137-07-1 . Проверено 5 февраля 2014 г.
^ Jump up to: ^а ^б ^с Коулишоу, МФ (1984). «Дизайн языка REXX» (PDF) . IBM Systems Journal . 23 (4): 333. дои : 10.1147/sj.234.0326 . Проверено 23 января 2014 г. Может ли новая функция вызывать сильное удивление? Если пользователь случайно неправильно применил функцию и приводит к непредсказуемому результату, эта функция имеет высокий фактор удивления и, следовательно, нежелательна. Если необходимая функция имеет высокий коэффициент удивления, может потребоваться ее перепроектирование.
^ Саутворт, Р.Н. (декабрь 1967 г.). Саутворт, Р.Н. (ред.). «Предложение по PL/I Псевдоимени» . Уведомления ACM SIGPLAN . 2 (12) (Бюллетень PL/I № 5 изд.): 6. doi : 10.1145/1139502.1139504 . ISSN 0362-1340 . S2CID 12180929 .
^ Дата, CJ (11 февраля 2022 г.). Мечтания о базе данных, том I: Переработанные и возрожденные сочинения о реляционных материалах . Технические публикации. Глава 2, ссылка 36. ISBN. 978-1-63462-984-3 . Как однажды заметил мне мой друг (это, должно быть, где-то в конце 1960-х годов), что бы вы ни говорили об этом, есть одна вещь, которой PL/I совершенно точно не является, и это «язык наименьшего удивления».
^ Трамбле, Жан-Поль; Соренсон, Пол Г. (1985). Теория и практика написания компиляторов . Нью-Йорк: МакГроу-Хилл. ISBN 9780070651616 . PL/I здесь является главным плохим примером; он усыпан конструкциями, которые не делают то, что думает программист, как показано на примере ФИКСИРОВАННОГО разделения.
^
Несколько источников:
- Холт, Ричард К. (май 1973 г.). «Обучение смертельной болезни: (или) вводное компьютерное программирование с использованием PL/I» . Уведомления ACM SIGPLAN . 8 (5): 8–23. дои : 10.1145/986948.986950 . к сожалению, выражение «25 + 1/3» дает 5,33333333333333.
- Голден, Дональд (октябрь 1980 г.). «Призыв к дружественному программному обеспечению» . Заметки по разработке программного обеспечения ACM SIGSOFT . 5 (4): 4–5. дои : 10.1145/1010884.1010885 . Чтобы программист, не владеющий PL/I, не пришел к ошибочному выводу, что PL/I не имеет недостатков, рассмотрим следующие примеры враждебности PL/I. Правил преобразования типов в PL/I достаточно, чтобы вызвать у программистов язву. Какой еще язык выдаст фатальную ошибку при вычислении выражения (25 + 1/3)? (Так же плохо, если вы отключите проверку ошибок, результат вычисления выражения будет 5,3333...)
- Стэнсифер, Райан Д. (1995). Изучение языков программирования . Энглвуд Клиффс, Нью-Джерси: Прентис Холл. п. 123. ИСБН 978-0-13-726936-5 . PL/I в этом отношении печально известен, поскольку он преобразует практически любой тип в любой другой тип, иногда с удивительными результатами. Рассмотрим выражение 1/3 + 25. В PL/I это выражение имеет значение 5,33333333333. Почему? Одна треть вычисляется с точностью до 15 цифр, 14 справа от десятичной точки. Затем 25 приводится к той же точности, при этом теряется старшая цифра 2! Это вызывает ошибку в PL/I, но по умолчанию ее игнорируют. Впервые это появилось в печати у Бэррона в 1968 году, где оно рассматривается как нарушение народного закона языкового дизайна: «закона наименьшего удивления».
- «Enterprise PL/I для z/OS 5.3 — Справочник по языку» (PDF) . ИБМ. Март 2021 г. стр. 57–62. Рассмотрим следующее выражение: 25+1/3. Результат вычисления этого выражения не определен, и возникает условие FIXEDOVERFLOW, поскольку деление FIXED приводит к значению максимальной точности, определенной реализацией. [...] Результаты двух оценок показаны в Таблице 29.
^ Бержерон, РД; Ганнон, доктор юридических наук; Шектер, ДП; Томпа, ФРВ; Дам, А. Ван (1972). «Языки системного программирования». Достижения в области компьютеров . 12 : 175–284. дои : 10.1016/s0065-2458(08)60510-0 . ISBN 9780120121120 .
^ Зальцер, Дж. Х.; Каашук, Франс (2009). Принципы проектирования компьютерных систем: введение . Морган Кауфманн. п. 85. ИСБН 978-0-12-374957-4 .
^ Петрутсос, Евангелос (2010). Владение Microsoft Visual Basic 2010 . Уайли. п. 133. ИСБН 978-0-470-53287-4 .
^ Блох, Джошуа (2006). «Как разработать хороший API и почему это важно» . Продолжение OOPSLA '06. Сопровождение 21-го симпозиума ACM SIGPLAN по системам, языкам и приложениям объектно-ориентированного программирования . Ассоциация вычислительной техники. стр. 506–7. дои : 10.1145/1176617.1176622 . ISBN 1-59593-491-Х . S2CID 27230400 .
^ Вивиан (21 июня 2013 г.). «Сочетания клавиш для Gmail» . Гугл Инк . Проверено 27 июля 2013 г.
^ «Сочетания клавиш для YouTube – Справка YouTube» . support.google.com . Проверено 16 августа 2022 г.
^ «Использование сочетаний клавиш» . Атласиан . Проверено 27 июля 2013 г.
^ Кейзер, Г. (1 марта 2010 г.). «Microsoft: не нажимайте клавишу F1 в Windows XP» . Компьютерный мир . Проверено 10 ноября 2019 г.
^ «Почему система счисления для parseInt в JavaScript по умолчанию равна 8?» . Переполнение стека . 8 апреля 2011 г.
^ "parseInt()" , Сеть разработчиков Mozilla (MDN) , 15 марта 2024 г. Если входная строка начинается с "0" (ноль), предполагается, что система счисления равна 8 (восьмеричному) или 10 (десятичному). Выбор именно системы счисления зависит от реализации. ECMAScript 5 поясняет, что следует использовать 10 (десятичное число), но пока не все браузеры поддерживают это.
^ «Часто задаваемые вопросы по FreeBSD 2.X, 3.X и 4.X» . FreeBSD. 11 июня 2002 г. Проверено 15 февраля 2023 г.

Внешние ссылки

Принцип наименьшего удивления в Портлендском репозитории шаблонов

[4] Альтернативно закон наименьшего сюрприза или правило наименьшего сюрприза . ^[2]^[3]

[1] Зеебах, Питер (1 августа 2001 г.). «Принцип наименьшего удивления» . Капризный пользователь . IBM DeveloperWorks . Проверено 23 января 2014 г.

[Raymond2004-2] Jump up to: ^а ^б ^с ^д Раймонд, Эрик Стивен (2003). «Применение правила наименьшего сюрприза». Искусство программирования для Unix . faqs.org. п. 20. ISBN 978-0-13-142901-7 . Проверено 23 августа 2020 г.

[3] Джеймс, Джеффри (1987). Дао программирования . Информационные книги. 4.1. ISBN 0-931137-07-1 . Проверено 5 февраля 2014 г.

[rexx-5] Jump up to: ^а ^б ^с Коулишоу, МФ (1984). «Дизайн языка REXX» (PDF) . IBM Systems Journal . 23 (4): 333. дои : 10.1147/sj.234.0326 . Проверено 23 января 2014 г. Может ли новая функция вызывать сильное удивление? Если пользователь случайно неправильно применил функцию и приводит к непредсказуемому результату, эта функция имеет высокий фактор удивления и, следовательно, нежелательна. Если необходимая функция имеет высокий коэффициент удивления, может потребоваться ее перепроектирование.

[6] Саутворт, Р.Н. (декабрь 1967 г.). Саутворт, Р.Н. (ред.). «Предложение по PL/I Псевдоимени» . Уведомления ACM SIGPLAN . 2 (12) (Бюллетень PL/I № 5 изд.): 6. doi : 10.1145/1139502.1139504 . ISSN 0362-1340 . S2CID 12180929 .

[7] Дата, CJ (11 февраля 2022 г.). Мечтания о базе данных, том I: Переработанные и возрожденные сочинения о реляционных материалах . Технические публикации. Глава 2, ссылка 36. ISBN. 978-1-63462-984-3 . Как однажды заметил мне мой друг (это, должно быть, где-то в конце 1960-х годов), что бы вы ни говорили об этом, есть одна вещь, которой PL/I совершенно точно не является, и это «язык наименьшего удивления».

[8] Трамбле, Жан-Поль; Соренсон, Пол Г. (1985). Теория и практика написания компиляторов . Нью-Йорк: МакГроу-Хилл. ISBN 9780070651616 . PL/I здесь является главным плохим примером; он усыпан конструкциями, которые не делают то, что думает программист, как показано на примере ФИКСИРОВАННОГО разделения.

[9] Несколько источников:
Холт, Ричард К. (май 1973 г.). «Обучение смертельной болезни: (или) вводное компьютерное программирование с использованием PL/I» . Уведомления ACM SIGPLAN . 8 (5): 8–23. дои : 10.1145/986948.986950 . к сожалению, выражение «25 + 1/3» дает 5,33333333333333.
Голден, Дональд (октябрь 1980 г.). «Призыв к дружественному программному обеспечению» . Заметки по разработке программного обеспечения ACM SIGSOFT . 5 (4): 4–5. дои : 10.1145/1010884.1010885 . Чтобы программист, не владеющий PL/I, не пришел к ошибочному выводу, что PL/I не имеет недостатков, рассмотрим следующие примеры враждебности PL/I. Правил преобразования типов в PL/I достаточно, чтобы вызвать у программистов язву. Какой еще язык выдаст фатальную ошибку при вычислении выражения (25 + 1/3)? (Так же плохо, если вы отключите проверку ошибок, результат вычисления выражения будет 5,3333...)
Стэнсифер, Райан Д. (1995). Изучение языков программирования . Энглвуд Клиффс, Нью-Джерси: Прентис Холл. п. 123. ИСБН 978-0-13-726936-5 . PL/I в этом отношении печально известен, поскольку он преобразует практически любой тип в любой другой тип, иногда с удивительными результатами. Рассмотрим выражение 1/3 + 25. В PL/I это выражение имеет значение 5,33333333333. Почему? Одна треть вычисляется с точностью до 15 цифр, 14 справа от десятичной точки. Затем 25 приводится к той же точности, при этом теряется старшая цифра 2! Это вызывает ошибку в PL/I, но по умолчанию ее игнорируют. Впервые это появилось в печати у Бэррона в 1968 году, где оно рассматривается как нарушение народного закона языкового дизайна: «закона наименьшего удивления».
«Enterprise PL/I для z/OS 5.3 — Справочник по языку» (PDF) . ИБМ. Март 2021 г. стр. 57–62. Рассмотрим следующее выражение: 25+1/3. Результат вычисления этого выражения не определен, и возникает условие FIXEDOVERFLOW, поскольку деление FIXED приводит к значению максимальной точности, определенной реализацией. [...] Результаты двух оценок показаны в Таблице 29.

[10] Холт, Ричард К. (май 1973 г.). «Обучение смертельной болезни: (или) вводное компьютерное программирование с использованием PL/I» . Уведомления ACM SIGPLAN . 8 (5): 8–23. дои : 10.1145/986948.986950 . к сожалению, выражение «25 + 1/3» дает 5,33333333333333.

[11] Голден, Дональд (октябрь 1980 г.). «Призыв к дружественному программному обеспечению» . Заметки по разработке программного обеспечения ACM SIGSOFT . 5 (4): 4–5. дои : 10.1145/1010884.1010885 . Чтобы программист, не владеющий PL/I, не пришел к ошибочному выводу, что PL/I не имеет недостатков, рассмотрим следующие примеры враждебности PL/I. Правил преобразования типов в PL/I достаточно, чтобы вызвать у программистов язву. Какой еще язык выдаст фатальную ошибку при вычислении выражения (25 + 1/3)? (Так же плохо, если вы отключите проверку ошибок, результат вычисления выражения будет 5,3333...)

[12] Стэнсифер, Райан Д. (1995). Изучение языков программирования . Энглвуд Клиффс, Нью-Джерси: Прентис Холл. п. 123. ИСБН 978-0-13-726936-5 . PL/I в этом отношении печально известен, поскольку он преобразует практически любой тип в любой другой тип, иногда с удивительными результатами. Рассмотрим выражение 1/3 + 25. В PL/I это выражение имеет значение 5,33333333333. Почему? Одна треть вычисляется с точностью до 15 цифр, 14 справа от десятичной точки. Затем 25 приводится к той же точности, при этом теряется старшая цифра 2! Это вызывает ошибку в PL/I, но по умолчанию ее игнорируют. Впервые это появилось в печати у Бэррона в 1968 году, где оно рассматривается как нарушение народного закона языкового дизайна: «закона наименьшего удивления».

[13] «Enterprise PL/I для z/OS 5.3 — Справочник по языку» (PDF) . ИБМ. Март 2021 г. стр. 57–62. Рассмотрим следующее выражение: 25+1/3. Результат вычисления этого выражения не определен, и возникает условие FIXEDOVERFLOW, поскольку деление FIXED приводит к значению максимальной точности, определенной реализацией. [...] Результаты двух оценок показаны в Таблице 29.

[10] Бержерон, РД; Ганнон, доктор юридических наук; Шектер, ДП; Томпа, ФРВ; Дам, А. Ван (1972). «Языки системного программирования». Достижения в области компьютеров . 12 : 175–284. дои : 10.1016/s0065-2458(08)60510-0 . ISBN 9780120121120 .

[SaltzerKaashoek2009-11] Зальцер, Дж. Х.; Каашук, Франс (2009). Принципы проектирования компьютерных систем: введение . Морган Кауфманн. п. 85. ИСБН 978-0-12-374957-4 .

[Petroutsos2010-12] Петрутсос, Евангелос (2010). Владение Microsoft Visual Basic 2010 . Уайли. п. 133. ИСБН 978-0-470-53287-4 .

[13] Блох, Джошуа (2006). «Как разработать хороший API и почему это важно» . Продолжение OOPSLA '06. Сопровождение 21-го симпозиума ACM SIGPLAN по системам, языкам и приложениям объектно-ориентированного программирования . Ассоциация вычислительной техники. стр. 506–7. дои : 10.1145/1176617.1176622 . ISBN 1-59593-491-Х . S2CID 27230400 .

[Gmail_Keyboard_Shortcuts-14] Вивиан (21 июня 2013 г.). «Сочетания клавиш для Gmail» . Гугл Инк . Проверено 27 июля 2013 г.

[15] «Сочетания клавиш для YouTube – Справка YouTube» . support.google.com . Проверено 16 августа 2022 г.

[Jira_Using_Keyboard_Shortcuts-16] «Использование сочетаний клавиш» . Атласиан . Проверено 27 июля 2013 г.

[17] Кейзер, Г. (1 марта 2010 г.). «Microsoft: не нажимайте клавишу F1 в Windows XP» . Компьютерный мир . Проверено 10 ноября 2019 г.

[18] «Почему система счисления для parseInt в JavaScript по умолчанию равна 8?» . Переполнение стека . 8 апреля 2011 г.

[19] "parseInt()" , Сеть разработчиков Mozilla (MDN) , 15 марта 2024 г. Если входная строка начинается с "0" (ноль), предполагается, что система счисления равна 8 (восьмеричному) или 10 (десятичному). Выбор именно системы счисления зависит от реализации. ECMAScript 5 поясняет, что следует использовать 10 (десятичное число), но пока не все браузеры поддерживают это.

[20] «Часто задаваемые вопросы по FreeBSD 2.X, 3.X и 4.X» . FreeBSD. 11 июня 2002 г. Проверено 15 февраля 2023 г.

[1]

[а]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[2]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[3]