moby

Все программисты с Марса, все пользователи с Венеры

Из всех возможностей своего PDA я использую только две, остальные оказались ненужными или неудобными. Во-первых, я читаю на нём книги с помощью Haali Reader, а, во-вторых, пользуюсь to-do list, да и то исключительно для составления списка покупок, которые нужно сделать в продуктовом магазине.

Внешне этот to-do list крайне прост: список строк с квадратиком слева от каждой из них; в квадратике можно поставить галочку. Есть у этой незамысловатой программы и меню, в котором особо следует заметить два пункта:
  • Active tasks
  • Completed tasks
Очевидно, что все задачи делятся на активные и выполненные. Изначально я вижу на экране и те, и другие. Если я выберу в меню пункт «Active tasks», то стану видеть только активные, а при следующем раскрытии меню возле строки «Active tasks» будет стоять галочка. Итак, я вижу только активные задачи (а включил я этот режим год назад и уже забыл, как в него попал), и хочу теперь увидеть все задачи. Внимание, вопрос: что мне надо выбрать в меню?

Вот как я рассуждаю: сейчас я вижу активные задачи, и пункт «Active tasks» отмечен галочкой. Я не вижу выполненных задач, и пункт «Completed tasks» не отмечен. Вероятно, галочками отмечаются категории задач, которые должны отображаться. В дополнение к активным задачам, которые я уже вижу, я хочу также увидеть и выполненные задачи, значит, мне нужно добиться, чтобы строка «Completed tasks» была отмечена галочкой. Обычно, если я хочу, чтобы возле пункта меню появилась галочка, мне нужно на него нажать. Разумеется, подобное решение я принимаю скорее интуитивно, но за ним действительно стоят примерно такие рассуждения.

После секундных раздумий я выбираю «Completed tasks» и вижу… только выполненные задачи! В меню после этого галочка стоит только возле строки «Completed tasks», но не «Active tasks». Со второй попытки я понимаю, что для того, чтобы увидеть все задачи, нужно убрать галочку с того пункта меню, возле которого она стоит, и тем самым вернуть систему к «обычному» состоянию (в противоположность «специальным» режимам показа только активных или только выполненных задач).

Разумеется, я давно привык к такому поведению этой программы, но не столько принял, сколько запомнил «неправильность», наподобие того, как мне пришлось запомнить, что горячая и холодная вода у меня в ванной обозначены на смесителе неправильно. Подходя к ванне, я автоматически вспоминаю: «наоборот!» — и наклоняю регулятор смесителя в сторону, обозначенную красным цветом, чтобы получить холодную воду. Точно так же, открывая меню в to-do list, я вспоминаю, что оно устроено «наоборот».

Раньше, когда я встречал тут и там подобные «наоборот» устроенные интерфейсные решения, я принимал их за ошибки или недоработки проектировщиков. Однако подобные «ошибки» встречаются довольно часто и носят схожий характер, укладывающийся в некую систему. Более того, именно такие решения чаще всего встречаются в программах и устройствах, которые пользователи, не являющиеся техническими специалистами, обычно характеризуют как простые, понятные, интуитивные и удобные в использовании. Похоже, имеет смысл говорить о существовании двух подходов к интерфейсу между человеком и машиной, а то и двух систем мышления вообще. Возможно, я выбрал для них не лучшие названия, да и вообще наверняка их уже кто-то назвал и изучил, но, тем не менее, попробую дать им краткие характеристики.
Объектно-ориентированный подход
Этот подход чаще встречается у технических специалистов, особенно программистов. На центральном месте — объект (например, документ, или же система в целом). Объект находится в одном из множества состояний и переходит из состояния в состояние под воздействием различных факторов, в том числе действий пользователя. Для того, чтобы управлять объектом, важно знать, в каком состоянии он находится в данный момент, поэтому при объектно-ориентированном подходе большое внимание уделяется информативности интерфейса, то есть его способности доносить до пользователя информацию о текущих состояниях объектов. Стоящая перед пользователем задача воспринимается как разница между текущим и желаемым состояниями системы и решается в терминах управляющих воздействий, необходимых для перевода системы в нужное состояние. Для успешного решения задачи требуется понимание структуры системы, состояний, в которых она может находиться, и способов перехода между ними, поэтому при объектно-ориентированном подходе ценится документация, объясняющая концепции, принципы, организацию системы в целом.
Процедурно-ориентированный подход
Этот подход преобладает у людей, не являющихся техническими специалистами. На центральном месте — задача. Чтобы можно было успешно решить задачу, она должна входить в набор задач, для решения которых предназначены данная программа или устройство (в идеале), или хотя бы должна быть возможность представить задачу как последовательность таких подзадач. Для решения задачи нужно применить к системе то управляющее воздействие, в ответ на которое система выдаёт желаемый результат. Поэтому ценится документация, приводящая подробные пошаговые процедуры для решения типовых задач. Поскольку узким местом подхода является выяснение того, какое управляющее воздействие нужно для решения той или иной задачи, при проектировании интерфейсов уделяется внимание повышению очевидности этих воздействий (панели инструментов, контекстные подсказки).
О процедурно-ориентированном подходе мне писать сложно, так как мне он не свойственен, и всё, что спроектировано так, я воспринимаю как неестественное. Те выводы, которые я о нём делаю, основаны не на личном опыте применения этого подхода, а на результатах анализа следующих ему систем.

Меня удивляет не само существование этих двух подходов, а такая пропасть между ними, приводящая к тому, что люди, следующие одному из них, не могут даже поставить себя на место тех, кому ближе другой подход. Существование двух принципиально разных способов мышления отвечает на многие вопросы:
  • Почему программисты не могут придумать удобный интерфейс для непрограммистов?
  • Почему у телевизоров и видеомагнитофонов такие «дурацкие» меню, что зачастую опытный программист не может настроить их без инструкции?
  • Почему «простыми и удобными» программами для обработки изображений, которые часто прилагаются бесплатно к сканерам и цифровым фотоаппаратам, невозможно пользоваться?
  • Почему на домофоне после набора номера квартиры, который может быть одно-, двух-, или трёхзначным, не нужно нажимать клавишу «Enter»?
  • Почему в интерфейсе бытовой техники так часто применяются автоматические переходы из состояния в состояние по истечению интервала времени без пользовательского воздействия, которые так раздражают многих программистов?
  • Почему многие люди не способны освоить программирование?
С другой стороны, появляются новые вопросы:
  • Является ли склонность к тому или иному из двух подходов врождённой или же приобретается с воспитанием?
  • Может ли человек, следующий одному подходу, развить в себе способность пользоваться другим?
  • Влияет ли школьное и вузовское образование на формирование того или иного подхода?
  • Определяет ли объектно-ориентированный подход выбор технической профессии, или наоборот?
В заключение — традиционный опрос. Пожалуйста, не голосуйте, если не прочли статью целиком.

Poll #813100 Объектно-ориентированный или процедурно-ориентированный подход?

Описание какого из подходов лучше характеризует ваш способ мышления?

Объектно-ориентированный подход
20(62.5%)
Процедурно-ориентированный подход
2(6.2%)
Третий подход, не описанный здесь (пожалуйста, напишите комментарий)
3(9.4%)
Подразделение на два подхода в корне неверно (пожалуйста, напишите комментарий)
7(21.9%)

UPDATE: Согласен с kalinka_malinka. Эта запись — пример того, как проводить заведомо нерепрезентативные исследования.

UPDATE: Ещё один интересный аспект той же проблемы.

In English: Programmers are from Mars, Users are from Venus
Интересно было бы обсудить
1. Думаю, что понять, о чем ты спрашиваешь смогут лишь люди с объектно-ориентированным подходом.

2. Хотелось бы обсудить влияние воспитания, образования, выбора профессии на способ человека вести себя "процедурно" или "объектно". Но к сожалению, участвовать в обсуждении смогут лишь те, кто смог быть в шкуре человека с иным подходом (и понимать это).
Я знаю людей, с крайне "объектным" подходом к окружающему миру, понимающих "процедурных" людей (это ты, feldgendler). Я знаю людей с неопределенным подходом, которые ведут себя и как "объектные", и как "процедурные" (это я). Но я не знаю людей с "процедурным" мышлением, которые способны понять людей с "объектным" мышлением.

3. Судя по первому комментарию, до конца дочитают немногие, скорее всего они охарактеризуют себя как людей с объектно-ориентированным подходом.

4. Интересно, какова связь между предпочтением человеком-логиком объектно-ориентированного подхода, а человеком-сенсориком -- процедурно-ориентированного? А также интересно соотношение количества женщин и мужчин с объектно-ориентированным подходом.
Re: Интересно было бы обсудить
Рассуждать так и такими словами способна только жена программиста.
Я не задумываясь пользуюсь обоими, автоматически из контекста.
Пока я читаю твою длинную статью, ответь мне - какой у тебя PDA. Ты ведь не хвалился вроде еще.
Потом я отвечу на твой опрос и расскажу, как я юзаю своего зверька. А надо сказать, что юзаю я его нещадно, и не только халиридером.
iPAQ h1910. Давно уже, года полтора. Да не о том пост был... Впрочем, ладно. А у тебя какой?
Я что-то не увидел связи твоего примера и последующих рассуждений. Просто возможность видеть все задачи - более редкая задача, чем видеть только несделанные, и, возможно, только сделанные (хотя это уже менее очевидно). Вот разработчики и сэкономили 1 пункт в меню "показать все".

Я с твоими терминами не совсем согласен. Правильнее будет просто разделить - одни вникают в логику работы системы, а другие запоминают набор приёмов, необходимых для выполнения той или иной задачи. Ведь далеко не каждая система даже на продвинутом уровне осознаётся как конгломерат объектов. Vim, например - я довольно давно пишу для него скрипты, но никаких объектов там нет.

Противопоставление подходов тоже не совсем верно. Ты можешь спуститься на уровень глубже в систему, свести всё к более простым (а может, и просто - более привычным для тебя) правилам, но сами эти правила тоже будут существовать как данность. Так что не совсем понятно, как ты можешь не осознавать "процедурный" подход - ведь описание каждого из объектов даётся именно перечислением его методов и как добиться от объекта той или иной задачи.

В принципе, "чисто процедурный" подход возможен - это полное отсутствие понимания логики работы программы, и нацеленность на решение ей 1-2 задач. У меня такое бывает - когда я вижу что-то новое для меня и у меня нет желания разбираться.
> Просто возможность видеть все задачи - более редкая задача, чем видеть только несделанные, и, возможно, только сделанные (хотя это уже менее очевидно). Вот разработчики и сэкономили 1 пункт в меню "показать все". (выделение моё)

Сейчас ты рассуждаешь процедурно-ориентировано. Кстати, если разработчики хотели сэкономить, то для этого были и другие способы, самый простой из которых -- переформулировать пункты меню: Active tasks only, Completed tasks only.

> Vim, например - я довольно давно пишу для него скрипты, но никаких объектов там нет.

Объекты там -- текст, курсор, выделение, буфер или что там ещё есть. Если ты пишешь скрипты, то обязательно думаешь об этих объектах и о том, как ты хочешь изменить их состояния.

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

Вовсе нет. При объектном подходе описание объекта даётся как описание пространства его состояний и перечисление возможных переходов между ними. Отображение своих задач на эти переходы пользователь делает уже сам.
>Почему на домофоне после набора номера квартиры, который может быть одно-, двух-, или трёхзначным, не нужно нажимать клавишу «Enter»?
Я общался только с такими, где нужно было нижимать «Enter» (Вызов).

>Почему программисты не могут придумать удобный интерфейс для непрограммистов?
А как же Apple?

Я, вообще-то, со многим не согласен, но слишком ленив, что б все это отмечать)
Не знаю, что там было у Apple в начале, но то, что сейчас, 100% придумали не программисты, а грамотные психологи, понимающие модель мышления своей целевой аудитории.
Я проголосовал за последний пункт. Я сейчас подумал и мне показалось, что мышление у программистов и, следовательно, создаваемые ими интерфейсы просто более структурированы. Возьмём для примера панель управления стиральной машинкой LG:



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

В общем, мне кажется, мышление людей действительно можно разделить на два подхода, но разделяются они исключительно умением (возможностью) логически группировать объекты. Это умение (или неумение), несомненно, не врождённое. Я вообще считаю, что люди делятся на «технарей» и «гуманитариев» классе так в пятом-шестом школы по простому принципу: кому-то повезло с учителем математики, а кому-то — с учителем литературы. Те, кому повезло с обоими, мучаются с выбором, куда поступать, а те, кому не повезло с учителями по этим предметам, идут работать после девятого класса.
> Я подозреваю, что если бы данный интерфейс нужно было бы реализовать в программе, программист не удержался бы от создания многоуровневых меню или дополнительных окон, но вряд ли бы расположил все элементы управления в одном окне на одном уровне.

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

> В общем, мне кажется, мышление людей действительно можно разделить на два подхода, но разделяются они исключительно умением (возможностью) логически группировать объекты. Это умение (или неумение), несомненно, не врождённое. Я вообще считаю, что люди делятся на «технарей» и «гуманитариев» классе так в пятом-шестом школы по простому принципу: кому-то повезло с учителем математики, а кому-то — с учителем литературы.

Те, кому повезло с учителем математики, приобрели способность логически группировать объекты. А какую ключевую способность приобрели те, кому повезло с учителем литературы? Это уже оффтопик, но интересно поразмышлять и на эту тему.
Сдаётся мне, слово Assistant там неспроста. Одни воспринимают вещи со скрытыми деталями внутреннего устройства как помощника, другие — как инструмент. Соответственно, вторые берут инструмент и решают им задачу, а первые просят помощника что-то им сделать. Я почти про это тоже как-то писал:

http://mivlad.livejournal.com/73493.html

Наверное, из тех первых получаются хорошие менеджеры :-)
Да, похоже на то. Возможно даже, что успешному менеджеру необходим процедурно-ориентированный подход, так же как программисту необходим объектно-ориентированный.
Я за (4) проголосовал, хотя он все равно не совсем точно отражает мой взгляд. Эти два подхода совсем не конфликтуют. Или не должны конфликтовать. Объекто-ориентированный подход нужен для формализации системы и реализации функциональности. В каком-то смысле это аппроксимация функции сплайнами. А процедурный подход нужен исключительно для предоставления интерфейса к построенной системе (функцию надо как-то назвать), т.к. человек, все-таки, мыслит в терминах задач (мне кажется), а не объектов и их взаимосвязей.

Эту разницу хорошо видно на примере моей любимой системы -- кнопки "Сделать Всю Работу". Она максимально user-friendly, при полном игнорировании структуры и отношений соответствующих объектов. В этой системе два подхода абсолютно четко разделены.
> Объекто-ориентированный подход нужен для формализации системы и реализации функциональности.

Ага! То есть ты утверждаешь, что объектно-ориентированный подход нужен только тому, кто систему делает, а пользователю он ни к чему. У меня совсем не так: я, именно будучи пользователем (PDA, домофона, микроволновки), следую объектно-ориентированному подходу, потому что иначе не умею.

> человек, все-таки, мыслит в терминах задач (мне кажется), а не объектов и их взаимосвязей (выделение моё)

Ты сейчас сказал за себя, а не за всех людей. Значит, тебе стоило всё же отвечать "Процедурно-ориентированный подход" (кстати, можно переголосовать -- ссылка "Заполнить опрос").

> Эту разницу хорошо видно на примере моей любимой системы -- кнопки "Сделать Всю Работу". Она максимально user-friendly, при полном игнорировании структуры и отношений соответствующих объектов.

Эта система -- доведённое до абсурда торжество процедурно-ориентированного подхода. Я бы такую кнопку ни за что не стал нажимать (и, следовательно, вообще пользоваться этой системой), поскольку не понимаю, как она работает, и не могу быть уверен в том, что получу именно желаемое.
> Почему на домофоне после набора номера квартиры, который может быть
> одно-, двух-, или трёхзначным, не нужно нажимать клавишу «Enter»?

У меня дома домофон, в котором есть кнопка "Вызов". Её надо нажимать после набора номера квартиры.
тут отпишусь, как раз про домофон.
Почему не нужна кнопка "Вызов", вернее почему она обычно не нужна.
Всё элементарно просто, что бы возникла коллизия между номерами вызываемых квартир, необходимо что бы в подъезде было минимум 90 квартир, это для квартир первого десятка и первой сотни соответственно (10 - 10X ), а для каждых последующих десятков и сотен разница будет расти на 90, желающие могут проверить сами. Так вот, насколько я знаю, у нас редко можно встретить дома в которых в подъезде более 90 квартир, а значит кнопка "Вызов" явно лишняя.
Перечитал на пару раз статью, попытался сформировать свое мнение.
Про подходы судить трудно, вроде само разбиение вполне обосновано, но есть ощущение что это разбиение не едиственно возможное. Что-то сумбурно получилось. В конкретном случае с приведенном меню, логика разработчиков для меня прозрачна. Сейчас буду нудно излагать эту логику, в моем естественно виденьи.
Собственно есть объект "Task", который может принимать два состояния: "Active" и "Completed".
Замечу что пересечение множеств "активных" и "выполненых" задач пустое, есть объект не может быть одновременно в двух состояниях.
Есть также объект "Task list", который отвечает за отображение всех задач, таким образом объект может принимать 3 состояния: отображать все задачи, отображать активные задачи, отображать выполненые задачи.
Логично преположить, что переход от первого состояния ко второму и третьему достигается путем наложения соответствующих фильтров, а так как фильтры взаимоисключающие (в силу пустого пересечения множеств), то наложение одного их фильтров автоматически отменяет наложение другого. Что собственно и реализовано. По-моему вполне юзабельно. То что пользователю необходимо объяснить что это фильтр, на это существует такая штука как "юзабилити" и некоторые основы, естественно разработчику интерфейса необходимо знать.

К чему все эту байду я написал, я еще сам не понял, ибо мысль ускользнула в процессе написания.

Парадигму "фильтр" обозначать надо словом only: Active tasks only. Чувствуешь разницу? Active tasks -- позитивный смысл, расширяющий множество видимых задач (показывать активные задачи). Active tasks only -- негативный смысл, сужающий множество видимых задач (не показывать другие задачи, кроме активных). Позитивные режимы отображения друг с другом отлично сочетаются, а негативные (в данном случае) -- нет.

Разумеется, эти тонкости имеют значение только при объектно-ориентированном подходе. При процедурно-ориентированном важна только задача: захотел увидеть активные задачи -- нажал Active tasks -- получил результат, захотел после этого увидеть выполненные задачи -- нажал Completed tasks -- получил результат.
Этих подходов целая пачка на самом деле. Ты описал только два, в которые укладываются некоторые интерфейсы.
Не очень понятны определения объектного и процедурного интерфейса.
командный интерфейс - это разовидность процедурной? тогда это мой выбор.
и как я полагаю люди с технической специальностью пользовать таким интерфейсом намного удобнее. впрочем как и людям нетехнических специальностей.
а объектный - я так до конца и не понял что имелось ввиду. или хотя бы пример приведите, plz.
многие задачи не очень хорошо накладываются на объектную модель, я думаю так же и с интерфейсами.
> Не очень понятны определения объектного и процедурного интерфейса.

А я их и не вводил. Я говорил о двух подходах к взаимодействию "человек-машина" (и о двух стилях мышления вообще).

> командный интерфейс - это разовидность процедурной?

Если имеется в виду интерес командной строки, то напрямую его использование не коррелирует с объектно-ориентированным или процедурно-ориентированным подходом. Но, похоже, чаще командная строка используется при объектно-ориентированном подходе. Система, управляемая командной строкой, -- это "инструмент", а не "решатель задач".
Хехе
В PalmOS этот раздел меню называется "show" и проблем не вызывает. Надо отметить галочками то, что достойно показывания.

Не зря, как оказалось, у меня винда для PDA вызывает отвращение априори :)
Re: Хехе
> В PalmOS этот раздел меню называется "show" и проблем не вызывает. Надо отметить галочками то, что достойно показывания.

А каково начальное состояние фильтра?

> Не зря, как оказалось, у меня винда для PDA вызывает отвращение априори :)

Я использую на PDA винду только из-за Haali Reader -- одна из двух программ, которыми пользуюсь, и не имеющая равных по юзабилити.
Вообще говоря, непонятно, чем существенно отличается
"Стоящая перед пользователем задача ... решается в терминах управляющих воздействий, необходимых для перевода системы в нужное состояние."
от
"Для решения задачи нужно применить к системе то управляющее воздействие, в ответ на которое система выдаёт желаемый результат."

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

Разумеется, в конечном счёте оба варианта эквивалентны, ведь и в том, и в другом случае задача в конце концов решается. Разница только в том, как думать об этом. При процедурно-ориентированном подходе ты ищешь свою задачу в списке задач, решаемых данной системой, и, если находишь (условно -- в левой колонке), то проделываешь управляющие манипуляции, описанные в правой колонке. При объектно-ориентированном подходе ты сперва задаёшься вопросами: в каком состоянии сейчас система? в какое состояние я хочу её привести? а затем, исходя из твоих знаний о системах такого типа, применяешь то управляющее воздействие, которое вызывает переход из первого состояния во второе.
Может я не совсем понял тему - а есть модульный подход?

Поскольку у меня здесь доморощенная терминология -- то не знаю. Что вы под этим понимаете?