Человеческий фактор в программировании
Шрифт:
Отчасти причина кроется в том, что первые текстовые процессоры, в основном благодаря добавленным функциям, выросли в текстовые редакторы, которые, в свою очередь, превратились в «текстовые издательства» с еще большими возможностями. Далее системы высокого класса, такие как WordPerfect и Word for Windows, стали почти неотличимы от полноценных настольных издательских программ с точки зрения их возможностей, хотя средства и методы у них довольно разные. Эти системы битком набиты фенечками и фитюльками, и нужно приложить немало усилий, чтобы заставить их работать в нужное время и в нужном месте.
Текстовые редакторы и растущий легион других важнейших инструментов стали жертвами прогрессирующего
Функции продаются. Обозреватели программного обеспечения уделяют им внимание и выделяют их в аккуратных сравнительных таблицах с помощью различных галочек, пунктирных линий и кружочков. Поставщики программного обеспечения соперничают за большее количество пунктов в списках функций, приводимых в рекламных буклетах. Потребители учатся одним взглядом отличать «полнофункциональный» персональный информационный менеджер от подобного пакета с ограниченной функциональностью. Большинство покупателей никогда не воспользуются всеми пунктами и операциями, однако им приятно просто сознавать, что такие функции есть на всякий маловероятный и непредвиденный случай. Чем больше, тем лучше, верно?
Прогрессирующий функционизм — это тяжелое хроническое заболевание. Синдром проявляется не в количестве функций, а в истории их появления, реализации в программном обеспечении и представлении пользователю. Прогрессирующий функционизм возникает в результате медленного разрастания функциональных возможностей и выражается в неоднородности пользовательских интерфейсов. Такие интерфейсы перегружены индивидуальными особенностями и специальными функциями, которые, как бородавки и карбункулы, могут появляться в самых необычных местах.
Прогрессирующий функционизм истощает систему, поскольку при добавлении нового элемента для него нужно найти разумное место, которого может и не быть. Если бы в ранних версиях текстовых редакторов не было непечатаемых комментариев, заранее предусмотренных в интерфейсе, то функции для их создания и редактирования были бы просто ку-да-нибудь приклеены. Примером может служить функциональная клавиша для импортирования/экспортирования текстового файла DOS, применение которой маловероятно, но вполне реально.
Прогрессирующий функционизм часто приводит к разбросу взаимосвязанных операций или пунктов выбора по разным частям пользовательского интерфейса. После четвертой или пятой редакции внесение десятков «добавлений» и «исправлений» приводит к тому, что пользовательский интерфейс покрывается слоем небольших довесков, разнообразных переключателей и приложений к меню. Со временем форма интерфейса все больше отражает внутренние программные ограничения. В ней проявляются трудности, с которыми сталкивались программисты при поиске места для размещения функций. Бывалые пользователи, чьи пальцы загрубели и искривились за многие годы применения этих функций, настолько привыкли к ним, что редко задумываются перед нажатием Ctrl-F5-C–C. Таким образом, они поощряют недобросовестных поставщиков программного обеспечения к еще большему интерфейсному варварству, поскольку новые функции не должны мешать применению старых.
На
самом деле пользователь хочет иметь (или ему нужен?) простой интерфейс для управления этими сложными системами. К сожалению, современное программное обеспечение очень часто оказывается простым только на поверхности. Вы убеждаетесь в его запутанности при попытке выполнить с его помощью какую-то реальную работу. Естественно, к этому моменту вы уже находитесь за пределами магазина по продаже программного обеспечения и связаны соглашением, упакованным в целлофановую оболочку.Сталкиваясь со сложностью, человек применяет фрагментирование. Простые или взаимосвязанные компоненты объединяются в фрагменты, которые можно мысленно воспринимать как целые единицы. Хороший интерфейс делает то же самое, сокращая до минимума общее количество идей и методов, которые пользователь должен усвоить. Для этого, во-первых, необходимо тщательное продумывание, а во-вторых, регулярная переработка во избежание беспорядка, вызываемого прогрессирующим функционизмом.
Например, с позиции человека, применяющего текстовый редактор, прямые линии, являющиеся линиями, есть линии. Пользователь хочет нарисовать линию и поместить ее в какое-то место. Независимо от того, проходит ли она под исправленным текстом, или отделяет основной текст от сносок, или формирует элементы таблицы, или обрамляет боковой комментарий, или представляет собой линейку размером 3 пункта в красивом заголовке для письма, — это всего лишь линия. Она выглядит как линия при выводе на печать. Мы называем ее линией, когда говорим коллеге: «Убери эту линию снизу». Однако в большинстве текстовых редакторов каждый из этих вариантов рассматривается как отдельное явление.
В моем старом текстовом редакторе было два основных способа рисования линий, или линеек, как говорят наборщики. Такое разделение в интерфейсе было обусловлено не внешними соображениями, исходящими от пользователя, а внутренними особенностями программы. В старой, более примитивной функции для рисования линий применялись текстовые символы. В последующих, более универсальных продуктах использовалась графика. Как это ни странно, старый способ был полу-WYSIWYG — вы рисовали с помощью клавиш управления курсором и могли сразу видеть результат. Новый способ требовал введения значений для типа линии, позиции и толщины. И даже после этого вы не могли увидеть результат без перехода в режим предварительного просмотра перед печатью, что было в традициях старых текстовых ограничений DOS.
Но представьте, какой текстовый редактор у меня теперь! В нем есть пять совершенно разных способов создания линий. В руководстве все они обозначены по-разному, а доступ к ним осуществляется с помощью разных меню и кнопок. Некоторые линии можно убрать, выделив их и нажав на кнопку удаления, а некоторые — нельзя. Очевидно, что это еще один случай прогрессирующего функционизма. В итоге появляется больше сложностей, чем нужно, а внешне все выглядит более сложным, чем есть на самом деле.
Безусловно, я твердо верю в эволюцию и в гибкость разработки программного обеспечения. Оно постоянно перерабатывается в соответствии с углубляющимся пониманием того, что мы хотим создавать с помощью инструментов и как их можно сделать наиболее полезными для нас. С другой стороны, эволюционный процесс в области разработки программного обеспечения может обернуться мешаниной из частей и компонентов, которые могут работать, но создавать при этом трудности для пользователя. После двух или трех основных релизов пользовательский интерфейс необходимо целиком перестраивать, чтобы для доступа к функциям требовалось меньшее количество элементов управления.