Принципы построения процедурных систем

Принцип ограниченной осведомленности. Есть такая пословица или просто изречение: «меньше знаешь - крепче спишь». Устройство системы должно быть скрыто от пользователя, дабы не забивать его голову "ненужными" фактами и не давать ему возможности испортить систему. Кроме того, большую часть системы можно не документировать или же остановиться на стадии технической документации, продажей которой можно при случае и заработать. А самое главное, что пользователь за всяким исправлением системы придет к разработчику и опять-таки заплатит за update или service pack. Пример: многие модели сотовых телефонов Siemens можно подключать к компьютеру, чтобы сохранять там телефонную книжку. Соединительный кабель, имеющий сертификат Siemens, стоит около 20 долл.. При наличии паяльника и схемы контактов можно было бы уложиться в 2-3 долл.. Поскольку техническая информация (схема контактов) восстановима из самого продукта (купленного кабеля за 20 долл.), соединительный кабель для Siemens, изготовленный без сертификата (но технически эквивалентный) будет стоит порядка 5 долл. (материал + работа).

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

Но этот принцип можно понимать двояко. Ведь, с другой стороны, задачу надо решать прямо сейчас и времени на то, чтобы разбираться, как сделать это решение изящным и эффективным, нет. В конце концов, что важнее - процесс или результат? Очевидно, результат. Значит, в качестве инструмента решения требуется нечто такое, что гарантированно можно использовать в любой ситуации, не расходуя время на изучение инструкций. Поскольку здесь могут иметь место механические действия пользователя, в которых он может ошибаться, (например, не все 10 раз подряд попасть мышкой по кнопкам очередного "мастера"), то в таких системах обязательно есть процедуры Undo и Redo, потому что механическая ошибка (и даже повторная!) - дело вполне обычное.

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

- Во-первых: процедур (кнопочек, рычагов, пунктов меню) в ней становится очень много. Чтобы пользователю легче было найти нужный рычаг, даже организуют специальные поисковые машинки. Иногда пункты меню располагаются так, что наглядность и простота не страдает (самые часто используемые - наверху, самые непопулярные - в глубине), но это приводит к тому, что самое интересное оказывается труднодоступным и про него никто и не вспоминает.

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

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

Более того, пользователь процедурной системы в определенном смысле привыкает к безответственности. Всякое воздействие на систему должно обеспечиваться всевозможными предупреждениями наподобие «Вы уверены, что хотите сделать это?» От этого все окошки могут позеленеть, а кнопочки - сморщиться!". Типичный признак процедурной системы - обилие запросов на подтверждение выбранного действия. Иногда подтверждения бывают двойные: за первым "Вы уверены?" следует "Вы действительно уверены?". Ответственный за систему - разработчик - обязан таким способом отмечать точки управления системой, в которых он перекладывает ответственность на пользователя. Выходит, пользователю предпочтительнее быть неуверенным - так меньше вероятность, что он что-нибудь испортит.

Таким образом, становится очевидно, что основным направлением развития процедурных систем будет создание все более полных и сбалансированных наборов решений для все большего числа прикладных областей. Не случайно слово "утилита" (utility) для обозначения программы пользователя было в таких системах заменено словом "приложение" (application) (то есть те же рычажки и кнопки, но в приложении к конкретной ситуации), а еще позже - на слово "решение" (solution). Обычно, помимо средств решения основного класса задач, такие системы имеют некоторый запас возможностей "на все случаи жизни" (согласно принципу перекрытия процедур). Пользоваться таким запасом не всегда неудобно. Зачастую, когда на одном компьютере соседствуют несколько процедурных систем, например CorelDraw, PhotoShop, MS Office и т. д. под одной Windows, их части вытесняют друг друга (вплоть до потери функциональности), напрасно "съедают" ресурсы компьютера и загромождают дисковое пространство.

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