Интерфейс: новые направления в проектировании компьютерных систем

Программное обеспечение вместо того, чтобы состоять из операционной системы и набора приложений, рассматривается человекоориентированным интерфейсом как набор команд, некоторые из которых являются трансформаторами, автоматически вызываемыми в тех случаях, когда тип данных, предусмотренных командой, не соответствует типу данных выбранного объекта. При этом может быть вызвано более одного трансформатора. Предположим, что с помощью одного трансформатора производится конвертация из А в В, а с помощью другого – из B в С. Если команда предусматривает обработку данных типа С, а данные выборки представляют собой тип А, то перед выполнением команды должны быть запущены два трансформатора. Если необходимых трансформаторов не имеется, никаких изменений с выборкой не производится. Пользователю при необходимости выдается специальное сообщение, а выборка остается без изменений.

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

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

В различных обзорах сообщается о большом количестве никогда не используемых элементов того или иного программного обеспечения. В последнее десятилетие это число возросло приблизительно с 15 % до почти 50 %. Это создает большой беспорядок. Если же вместо приложений использовать наборы команд, каждая из которых может быть установлена независимо от других, пользователи сведут показатели этой статистики почти до 0. Другими преимуществами такого подхода для разработчиков является возможность поступенчато улучшать свои продукты, а также более простым образом и чаще поставлять (т. е. продавать!) новые элементы приложений, поскольку в этом случае производителям не придется каждый раз выпускать весь пакет заново. Интернет является самым подходящим средством для осуществления таких многократных поштучных продаж.

Разработчики (необязательно те же, кто выпускает наборы прикладных команд) также могут производить трансформаторы. И они тоже могут продаваться поштучно. Если большинство пользователей регулярно использует большинство команд текстовой обработки, выпущенных разработчиком А

, и разработчик В придумает какую-то полезную команду, которую разработчик А не поставляет, то разработчик

В сможет продавать эту команду покупателям продукта, производимого разработчиком А. Однако разработчик В

может использовать другую структуру данных. В этом случае он может предложить также и трансформатор для перевода из одной структуры данных в другую, и наоборот. Если продуктом, производимым разработчиком А, пользуется большое число потребителей, разработчик В может создать версию данной команды, работающую непосредственно со структурой данных, предусмотренной разработчиком А. Кроме того, третий разработчик (С) может специализироваться на разработке трансформаторов. Для пользователей может стать обычной практикой покупать трансформаторы именно у таких разработчиков, а для разработчиков команд – давать лицензии на соответствующие трансформаторы. Эта коммерческая структура частично уже существует сегодня, и различные компании (например, DataViz) специализируются на разработке трансформаторов.