Процедура как суррогат поступка

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

Система в самом общем виде работает так: человек описывает, какой продукт он хочет получить, а машина рассказывает, какие действия надо для этого предпринять. Естественно, возможны варианты: часто человек не в состоянии вспомнить все свойства продукта, и машине приходится потихоньку выспрашивать их; так, например, устроен, "мастер подключения к Internet" в Windows 98 и прочие подобные ему "мастера" (wizards). Почти всегда стадия "какие действия предпринимать" этими мастерами и ограничивается: после того, как свойства продукта описаны, задачу уже можно решить, не посвящая пользователя в тонкости решения. Наконец (отличительная особенность процедурных систем!), под типовую пользовательскую задачу, скорее всего, найдется готовый вариант решения, так что пользователю останется только нажать кнопку, скажем, "форматировать текст" и наслаждаться результатом.

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

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

Легенда

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

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

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