Все программисты с Марса, все пользователи с Венеры
Из всех возможностей своего PDA я использую только две, остальные оказались ненужными или неудобными. Во-первых, я читаю на нём книги с помощью Haali Reader, а, во-вторых, пользуюсь to-do list, да и то исключительно для составления списка покупок, которые нужно сделать в продуктовом магазине.
Внешне этот to-do list крайне прост: список строк с квадратиком слева от каждой из них; в квадратике можно поставить галочку. Есть у этой незамысловатой программы и меню, в котором особо следует заметить два пункта:
Вот как я рассуждаю: сейчас я вижу активные задачи, и пункт «Active tasks» отмечен галочкой. Я не вижу выполненных задач, и пункт «Completed tasks» не отмечен. Вероятно, галочками отмечаются категории задач, которые должны отображаться. В дополнение к активным задачам, которые я уже вижу, я хочу также увидеть и выполненные задачи, значит, мне нужно добиться, чтобы строка «Completed tasks» была отмечена галочкой. Обычно, если я хочу, чтобы возле пункта меню появилась галочка, мне нужно на него нажать. Разумеется, подобное решение я принимаю скорее интуитивно, но за ним действительно стоят примерно такие рассуждения.
После секундных раздумий я выбираю «Completed tasks» и вижу… только выполненные задачи! В меню после этого галочка стоит только возле строки «Completed tasks», но не «Active tasks». Со второй попытки я понимаю, что для того, чтобы увидеть все задачи, нужно убрать галочку с того пункта меню, возле которого она стоит, и тем самым вернуть систему к «обычному» состоянию (в противоположность «специальным» режимам показа только активных или только выполненных задач).
Разумеется, я давно привык к такому поведению этой программы, но не столько принял, сколько запомнил «неправильность», наподобие того, как мне пришлось запомнить, что горячая и холодная вода у меня в ванной обозначены на смесителе неправильно. Подходя к ванне, я автоматически вспоминаю: «наоборот!» - и наклоняю регулятор смесителя в сторону, обозначенную красным цветом, чтобы получить холодную воду. Точно так же, открывая меню в to-do list, я вспоминаю, что оно устроено «наоборот».
Раньше, когда я встречал тут и там подобные «наоборот» устроенные интерфейсные решения, я принимал их за ошибки или недоработки проектировщиков. Однако подобные «ошибки» встречаются довольно часто и носят схожий характер, укладывающийся в некую систему. Более того, именно такие решения чаще всего встречаются в программах и устройствах, которые пользователи, не являющиеся техническими специалистами, обычно характеризуют как простые, понятные, интуитивные и удобные в использовании. Похоже, имеет смысл говорить о существовании двух подходов к интерфейсу между человеком и машиной, а то и двух систем мышления вообще. Возможно, я выбрал для них не лучшие названия, да и вообще наверняка их уже кто-то назвал и изучил, но, тем не менее, попробую дать им краткие характеристики.
Объектно-ориентированный подход
Этот подход чаще встречается у технических специалистов, особенно программистов. На центральном месте - объект (например, документ, или же система в целом). Объект находится в одном из множества состояний и переходит из состояния в состояние под воздействием различных факторов, в том числе действий пользователя. Для того, чтобы управлять объектом, важно знать, в каком состоянии он находится в данный момент, поэтому при объектно-ориентированном подходе большое внимание уделяется информативности интерфейса, то есть его способности доносить до пользователя информацию о текущих состояниях объектов. Стоящая перед пользователем задача воспринимается как разница между текущим и желаемым состояниями системы и решается в терминах управляющих воздействий, необходимых для перевода системы в нужное состояние. Для успешного решения задачи требуется понимание структуры системы, состояний, в которых она может находиться, и способов перехода между ними, поэтому при объектно-ориентированном подходе ценится документация, объясняющая концепции, принципы, организацию системы в целом.
Процедурно-ориентированный подход
Этот подход преобладает у людей, не являющихся техническими специалистами. На центральном месте - задача. Чтобы можно было успешно решить задачу, она должна входить в набор задач, для решения которых предназначены данная программа или устройство (в идеале), или хотя бы должна быть возможность представить задачу как последовательность таких подзадач. Для решения задачи нужно применить к системе то управляющее воздействие, в ответ на которое система выдаёт желаемый результат. Поэтому ценится документация, приводящая подробные пошаговые процедуры для решения типовых задач. Поскольку узким местом подхода является выяснение того, какое управляющее воздействие нужно для решения той или иной задачи, при проектировании интерфейсов уделяется внимание повышению очевидности этих воздействий (панели инструментов, контекстные подсказки).
О процедурно-ориентированном подходе мне писать сложно, так как мне он не свойственен, и всё, что спроектировано так, я воспринимаю как неестественное. Те выводы, которые я о нём делаю, основаны не на личном опыте применения этого подхода, а на результатах анализа следующих ему систем.
Меня удивляет не само существование этих двух подходов, а такая пропасть между ними, приводящая к тому, что люди, следующие одному из них, не могут даже поставить себя на место тех, кому ближе другой подход. Существование двух принципиально разных способов мышления отвечает на многие вопросы:
Poll Объектно-ориентированный или процедурно-ориентированный подход?
UPDATE: Согласен с kalinka_malinka. Эта запись - пример того, как проводить заведомо нерепрезентативные исследования.
UPDATE: Ещё один интересный аспект той же проблемы.
In English: Programmers are from Mars, Users are from Venus
Внешне этот to-do list крайне прост: список строк с квадратиком слева от каждой из них; в квадратике можно поставить галочку. Есть у этой незамысловатой программы и меню, в котором особо следует заметить два пункта:
- Active tasks
- Completed tasks
Вот как я рассуждаю: сейчас я вижу активные задачи, и пункт «Active tasks» отмечен галочкой. Я не вижу выполненных задач, и пункт «Completed tasks» не отмечен. Вероятно, галочками отмечаются категории задач, которые должны отображаться. В дополнение к активным задачам, которые я уже вижу, я хочу также увидеть и выполненные задачи, значит, мне нужно добиться, чтобы строка «Completed tasks» была отмечена галочкой. Обычно, если я хочу, чтобы возле пункта меню появилась галочка, мне нужно на него нажать. Разумеется, подобное решение я принимаю скорее интуитивно, но за ним действительно стоят примерно такие рассуждения.
После секундных раздумий я выбираю «Completed tasks» и вижу… только выполненные задачи! В меню после этого галочка стоит только возле строки «Completed tasks», но не «Active tasks». Со второй попытки я понимаю, что для того, чтобы увидеть все задачи, нужно убрать галочку с того пункта меню, возле которого она стоит, и тем самым вернуть систему к «обычному» состоянию (в противоположность «специальным» режимам показа только активных или только выполненных задач).
Разумеется, я давно привык к такому поведению этой программы, но не столько принял, сколько запомнил «неправильность», наподобие того, как мне пришлось запомнить, что горячая и холодная вода у меня в ванной обозначены на смесителе неправильно. Подходя к ванне, я автоматически вспоминаю: «наоборот!» - и наклоняю регулятор смесителя в сторону, обозначенную красным цветом, чтобы получить холодную воду. Точно так же, открывая меню в to-do list, я вспоминаю, что оно устроено «наоборот».
Раньше, когда я встречал тут и там подобные «наоборот» устроенные интерфейсные решения, я принимал их за ошибки или недоработки проектировщиков. Однако подобные «ошибки» встречаются довольно часто и носят схожий характер, укладывающийся в некую систему. Более того, именно такие решения чаще всего встречаются в программах и устройствах, которые пользователи, не являющиеся техническими специалистами, обычно характеризуют как простые, понятные, интуитивные и удобные в использовании. Похоже, имеет смысл говорить о существовании двух подходов к интерфейсу между человеком и машиной, а то и двух систем мышления вообще. Возможно, я выбрал для них не лучшие названия, да и вообще наверняка их уже кто-то назвал и изучил, но, тем не менее, попробую дать им краткие характеристики.
Объектно-ориентированный подход
Этот подход чаще встречается у технических специалистов, особенно программистов. На центральном месте - объект (например, документ, или же система в целом). Объект находится в одном из множества состояний и переходит из состояния в состояние под воздействием различных факторов, в том числе действий пользователя. Для того, чтобы управлять объектом, важно знать, в каком состоянии он находится в данный момент, поэтому при объектно-ориентированном подходе большое внимание уделяется информативности интерфейса, то есть его способности доносить до пользователя информацию о текущих состояниях объектов. Стоящая перед пользователем задача воспринимается как разница между текущим и желаемым состояниями системы и решается в терминах управляющих воздействий, необходимых для перевода системы в нужное состояние. Для успешного решения задачи требуется понимание структуры системы, состояний, в которых она может находиться, и способов перехода между ними, поэтому при объектно-ориентированном подходе ценится документация, объясняющая концепции, принципы, организацию системы в целом.
Процедурно-ориентированный подход
Этот подход преобладает у людей, не являющихся техническими специалистами. На центральном месте - задача. Чтобы можно было успешно решить задачу, она должна входить в набор задач, для решения которых предназначены данная программа или устройство (в идеале), или хотя бы должна быть возможность представить задачу как последовательность таких подзадач. Для решения задачи нужно применить к системе то управляющее воздействие, в ответ на которое система выдаёт желаемый результат. Поэтому ценится документация, приводящая подробные пошаговые процедуры для решения типовых задач. Поскольку узким местом подхода является выяснение того, какое управляющее воздействие нужно для решения той или иной задачи, при проектировании интерфейсов уделяется внимание повышению очевидности этих воздействий (панели инструментов, контекстные подсказки).
О процедурно-ориентированном подходе мне писать сложно, так как мне он не свойственен, и всё, что спроектировано так, я воспринимаю как неестественное. Те выводы, которые я о нём делаю, основаны не на личном опыте применения этого подхода, а на результатах анализа следующих ему систем.
Меня удивляет не само существование этих двух подходов, а такая пропасть между ними, приводящая к тому, что люди, следующие одному из них, не могут даже поставить себя на место тех, кому ближе другой подход. Существование двух принципиально разных способов мышления отвечает на многие вопросы:
- Почему программисты не могут придумать удобный интерфейс для непрограммистов?
- Почему у телевизоров и видеомагнитофонов такие «дурацкие» меню, что зачастую опытный программист не может настроить их без инструкции?
- Почему «простыми и удобными» программами для обработки изображений, которые часто прилагаются бесплатно к сканерам и цифровым фотоаппаратам, невозможно пользоваться?
- Почему на домофоне после набора номера квартиры, который может быть одно-, двух-, или трёхзначным, не нужно нажимать клавишу «Enter»?
- Почему в интерфейсе бытовой техники так часто применяются автоматические переходы из состояния в состояние по истечению интервала времени без пользовательского воздействия, которые так раздражают многих программистов?
- Почему многие люди не способны освоить программирование?
- Является ли склонность к тому или иному из двух подходов врождённой или же приобретается с воспитанием?
- Может ли человек, следующий одному подходу, развить в себе способность пользоваться другим?
- Влияет ли школьное и вузовское образование на формирование того или иного подхода?
- Определяет ли объектно-ориентированный подход выбор технической профессии, или наоборот?
Poll Объектно-ориентированный или процедурно-ориентированный подход?
UPDATE: Согласен с kalinka_malinka. Эта запись - пример того, как проводить заведомо нерепрезентативные исследования.
UPDATE: Ещё один интересный аспект той же проблемы.
In English: Programmers are from Mars, Users are from Venus