Легенда

Чтобы пользователь мог хотя бы отчасти  планировать и прогнозировать поведение  системы, он должен знать, как она  устроена и как работает. А поскольку  устроена система, как правило, непросто, приходится изобретать еще одну, упрощенную и не соответствующую действительности ее архитектуру, зато описанную в понятных пользователю терминах. Так возникает еще один способ взаимодействия с процедурной системой: посредством легенды. Легенда - это описание рычагов управления системой так, как если бы она только из них и состояла. Легенда хороша тем, что создает у пользователя ощущение, будто он отлично понимает устройство системы - пока следует предписанию. Недостаток легенды в том, что придерживаться ее всегда и во всем невозможно. Одни и те же - по легенде - объекты начинают вести себя в разных ситуациях по-разному, потому что соответствуют различным типам объектов системы. Типичный пример легенды - понятие иконки (значка, icon) в Windows. Иконки в обозревателе ведут себя не так, как некоторые иконки на рабочем столе, и совсем не так, как иконки в панели управления.

Пользователь  процедурной системы зачастую не знает, как именно он добился от нее желаемого результата и далеко не всегда может с первого раза воспроизвести свои действия. Нажимал-нажимал на кнопки - и вышло. Как? А кто ж ее знает. Здесь работает накопленный опыт общения с системой, возможно, даже некое представление об ее истинном устройстве, добытое из системы в обход предусмотренных каналов информации и оттого не поддающееся формализации. Явление это имеет название black magic (черная магия) или voodoo.

Принципы  построения

Принцип ограниченной осведомленности

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

Принцип гарантированных  навыков

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

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

Принцип перекрытия процедур

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

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

Принцип делегирования ответственности

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

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

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

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

Область применения

Каковы  достоинства процедурной системы? Во-первых, быстрота и однозначность реакции на предусмотренные ситуации. Если возникает задача, решение которой известно (а таких много), то дальнейшее - дело техники. Если задача нетиповая, то есть не имеет готового решения, ее либо можно разбить на последовательность типовых подзадач, либо скрепя сердце подогнать под существующую типовую и признать получившееся решение решением исходной задачи. Во-вторых, как только появляется возможность формализовать предписание, управляющее работой системы, человека можно бестрепетно заменять автоматом (как, например, автоматическая проверка диска в Windows). В-третьих, ускоренная программа обучения пользователя процедурной системы требует в основном заучивания и практически никаких знаний ни об устройстве машины, ни даже о самой системе. Наконец, ответственность за применение системы можно легко переложить на разработчика или на начальника, который приказал потянуть за рычаг; а это непременное требование в сферах деятельности, где высокая цена риска сочетается с информационными или должностными ограничениями.

Недостатки  процедурной системы. Один из них уже упоминался в следствии 2: подавление инициативы. Кроме всего прочего, человеку может быть чрезвычайно некомфортно работать в условиях, когда по своей воле он ничего ровным счетом сделать не в состоянии. К тому же подмена знаний о внутреннем устройстве системы легендой влечет за собой необратимость всякого воздействия: даже если в наборе процедур к "прямому" изменению объекта предусмотрено "обратное" (к примеру, вставка и удаление), после их поочередного применения исходный объект уже не получится. Скорее всего, он будет нести в себе следы прежнего объекта, а также и "прямого", и "обратного" изменений. Тут-то и приходит на помощь кнопочка Undo, которая не оперирует обратным воздействием, а работает с архивом версий объекта, выбирая оттуда предыдущую его копию. Кроме того, как неизвестно, каким образом система работает, так неизвестно и то, каким образом она не работает, то есть отчего происходят ошибки, отчего именно это сочетание процедур приводит к сбою и т. п. Словом, невозможно предсказать, когда и как именно произойдет следующий сбой системы, а когда он произошел - понять, что его вызвало, и как с этим бороться. Наконец, чем дальше задача от типовой (для которой имеется готовое решение), тем сложнее ее такой системе решить и тем сложнее предсказать качество продукта, который получится в результате использования не вполне подходящих процедур.

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

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

Информационные потоки и права доступа

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