Проект 'ПОтребитель'
Главная | Новости | Информация | Статьи | Программы
Законы | Ссылки | О проекте | Off topic


Дмитрий Карпов
Этот мерзкий, неудобный, противоестественный оконный интерфейс


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

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

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


Мне не нравятся оконные системы. Не только потому, что они медленно загружаются (есть такие, которые загружаются быстро), не потому, что жрут ресурсы машины (есть довольно экономные, по кр.мере по сравнению с остальными), не потому, что часто рушатся и требуют долгой нудной инсталляции (есть довольно стабильные и даже вообще зашитые в ПЗУ). Просто графический оконный интерфейс, по моему скромному мнению, - неудобный, в большинстве случаев ненужный, а часто просто вредный. И я могу доказать это;.. ну, по кр.мере, попробовать доказать.

Речь идет о MicroSoft Windows? Войны сторонников и противников MicroSoft давно уже стали напоминать средневековые войны за веру.

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

Почему же он неудобный?

Посмотрите на свой экран: если Вы не являетесь счастливым обладателем 21-дюймового монитора и видеокарты с разрешением 1600*1200 (которые стОят в несколько раз дороже остального компьютера), то, я уверен, подавляющую часть времени его целиком занимает задача в полноэкранном режиме. Если Вы работаете с несколькими задачами, Вы переключаетесь между ними - но каждая из них все-таки будет занимать экран целиком. Впрочем, большой монитор покупают те, кому надо работать в графике высокого разрешения (полиграфия, картография, чертежные работы), а при этих работах не до многооконности - даже такого разрешения подчас маловато. Так зачем же нужны в полноэкранных задачах элементы оконного интерфейса, которые только отъедают драгоценное экранное пространство?

А как быть с диалоговыми окнами настроек, свойств и т.д., которые имеет практически любое приложение?

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

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

Но оконный интерфейс облегчает работу пользователя.

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

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

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

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

А возвращаясь к теме компьютерного интерфейса, могу сказать, что мне надо делать мою работу. Если программа, с которой я работаю, удобна, ничего другого мне и не надо, а если нет - окна не помогут.

Но ведь именно многооконная система позволяет работать одновременно с несколькими задачами?

Большинство современных операционных систем действительно имеют многозадачность и графический оконный интерфейс, либо встроенный (MS-Windows, Mac-OS), либо в качестве оболочки (Unix X-windows, OS/2, Acorn RiscOS). Оконная система ассоциируется с многозадачностью, как правило, у тех, кто перешел от MS-DOS к MS-Windows или Macintosh. На самом деле многозадачность, причем вытесняющая, была изобретена задолго до не только оконного интерфейса, но и появления графических дисплеев - ее появление было связано с необходимостью одновременной работы многих пользователей на соответствующем количестве рабочих мест. Есть множество способов организации многозадачности; анализ этих способов не входит в тему данной статьи, но ни один не требует отображать одновременно на одном экране результат работы нескольких программ. Действительно, раз комплект устройств ввода (клавиатура, мышь, дигитайзер, ...) один, значит, пользователь в каждый момент времени работает только с одной задачей независимо от того, сколько их запущено.

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

Например?

Довольно интересный и удобный способ предоставляют современные Unix'ы. Вообще-то изначально Unix был задуман как система, которая подобно mainframe (большой машине) позволяет работать одновременно нескольким пользователям, каждый на своем терминале (это поддерживается и сейчас). Естественно, с самого начала поддерживались и вытесняющая многозадачность, и ограничение прав доступа к файлам и к управлению задачами (управление задачами - достаточно нетривиальная вещь для пользователя персонального компьютера, не знакомого с управлением сервером; имеется в виду возможность изменять приоритеты задач, запускать/останавливать процессы).

Первые Unix'ы были разработаны для многотерминальных машин типа PDP-11, однако при переносе Unix на desktop (на настольные машины), в т.ч. и персональные компьютеры, были придуманы "виртуальные консоли": при нажатии Alt вместе с функциональной клавишей F(номер) происходит переключение на консоль 'номер-1' (консоли нумеруются начиная с нуля, а клавиши с единицы).

Т.е. консолей не может быть больше 10..12?

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

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

Благодарные читатели иногда присылают дополнения. Вот одно из них:

Еще один способ, также придуманный в мире Unix - программа screen, названная в её собственной документации screen manager (аналогию с window manager видно?), хотя ее можно назвать и session manager'ом. Эта программа позволяет запустить из-под себя несколько различных программ, каждой из которых предоставит виртуальный текстовый терминал, аналогичный тому, который предоставляют виртуальные консоли. В отличие от виртуальных консолей, screen не предоставляет графических возможностей и возможности войти в систему под именем другого пользователя (выполнить программу - можно, эту возможность в Unix предоставляет, например, команда su), зато позволяет обходиться без доступа к настоящей консоли (например, у Вас настоящий терминал вроде VT100 или Вы дозвонились на хост терминальной программой вроде DOS'овского Telix или Unix'ового minicom), отсоединить всю сессию от одного терминала и подсоединиться к ней с другого (Вы можете отсоединиться, выйти из системы и уйти домой, а наутро, придя на работу, подсоединиться и продолжить работу с того места, в котором Вы ее вчера оставили; Вы можете также, перейдя в другой конец длинного здания, перехватить сессию с той машины, с которой Вы три минуты назад ушли), и даже работать в одной сессии нескольким пользователям. "Окно" в терминах screen является на самом деле полным экраном. Лишь иногда, по специальному запросу, screen выводит на несколько секунд служебную информацию в нижнюю строку экрана. Авторы screen реализовали замечательный принцип "лучший интерфейс - тот, которого пользователь не замечает".
Artem Chuprina

Совершенно другой метод реализован фирмой Apple на Newton Message Pad, который же изначально проектировался как портативный компьютер. Перед его создателями стояли две основные проблемы - габариты и вес - и они были удачно решены. Вес Newton'а составляет всего полкилограмма за счет перехода от аккумуляторов к четырем пальчиковым батарейкам при том, что Newton может работать сутки, а notebook - не более восьми часов; это удалось за счет отказа от жесткого диска в пользу Flash-ROM и использования процессора ARM вместо i*86. Сделать Newton карманным компьютером и при этом удобным в обращении удалось за счет упора на полноэкранные приложения - перемещаемыми остались только служебные программы типа "виртуальной клавиатуры". Об этом невозможно рассказать - это надо увидеть своими глазами. Те, кто с недоверием слушал о "карманном компьютере, распознающем рукописный текст", визжат от восторга при первом же столкновении с естественным интерфейсом "бумага и ручка" (где вместо бумаги - экран, по которому пишут специальной ручкой).

Полноэкранные приложения используются на Newton'е по одной причине: его экран и так мал, его буквально некуда дальше делить.

И да, и нет - именно отказ от оконного интерфейса позволяет сделать Newton, PalmPilot и Psion такими маленькими, а ведь для портативных компьютеров основные параметры оптимизации - размеры и вес. (Еще один столь же важный параметр оптимизации - энергопотребление; оно снижено в основном за счет отказа от жесткого диска, использования RISC-процессора вместо i*86-совместимого, ну и маленького экрана.)

А как же такие удобные вещи как point&click (укажи-и-щелкни) и drag&drop (перетащи-и-брось)?

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

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

Это еще зачем?

Иногда требуется. Например, я хочу послать кому-то вопрос или совет о том, что делать в тех или иных случаях, и надо описать конфигурацию, в которой та или иная программа работает (или не работает). Короче, я хочу скопировать текст, который я вижу на экране. Однако, по кр.мере программы MS-Windows позволяет копировать только то, что считают нужным. То, что они считают нужным, а не я! (Можно, конечно, копировать изображение экрана - это имеет как свои плюсы, так и минусы. В данном случае я говорю о тех данных, которые программа передала WindowsManager'у в виде текста, но которые нельзя скопировать как текст.)

Кроме того, система "наглядного копирования" имеет ряд подводных камней. Например, если я перетаскиваю мышкой выбранный файл из одного окна FileManager в другое, это, очевидно, указание копировать (или, может, перемещать?) файл. Но если я перетаскиваю его в текст какого-нибудь текстового редактора, то что должно быть помещено в текст - имя файла или его содержимое? А если содержимое - то оно должно быть вставлено как есть или должна быть создана ссылка на файл как включенный (многие системы умеют работать с такими ссылками - это позволяет внести изменения в какие-нибудь реквизиты и быть уверенным, что обновились все документы, использующие эти реквизиты). А если это запускаемый файл (интерпретируемый скрипт), то, может быть, надо поместить результат его работы - все, что будет выведено на стандартный вывод (stdout в языке C), как это происходит с CGI-скриптами в Web? Подобные неочевидности могут привести к серьезным проблемам у пользователей с не очень большим опытом или просто не столь тщательно изучившим взаимодействие программ друг с другом как их автор. Нам непрерывно вдалбливают необходимость наглядного интерфейса, но технология drag&drop весьма далека от наглядности; для работы с информацией (в противоположность работе с материальными объектами) эта технология скорее противоестественна.

Во многих программах используется очень неудобная система выделения. Например, в Word, Write и Notepad можно выделить один кусок текста, а в Excel и DOS-окне - один прямоугольный блок. Может, я плохо знаком с этими программами, но все попытки выделить два куска кончились неудачей. А вот в программах, имеющих дело со списками, (прежде всего, в файловых навигаторах) с помощью клавиш Ctrl и Shift можно выделить любой набор элементов (хотя после выделения сплошного блока с помощью "клик, Shift+клик" выделить второй блок у меня не получилось пришлось добавлять элементы с помощью "Ctrl+клик").

Как это ни странно, эта проблема имеет место в такой далекой от оконного интерфейса области, как стратегические игры. В старых играх (Dune'2) вообще было невозможно дать команду группе юнитов - приходилось давать команду каждому по отдельности. В WarCraft'II можно было выделять в группу до девяти юнитов и давать им общую команду, хотя некоторые команды группе юнитов отдать было нельзя (так называемые "специальные умения"); можно было также по одному добавлять и убирать юнитов из группы. А в C&C, появившейся раньше WarCraft'II, вообще было ценнейшее свойство - можно было выбрать группу и нажав "Ctrl+цифра", запомнить ее, а нажав "цифру", вновь выделить эту группу. (В WarCraft'II можно было только нажатием "Alt+клик" на юнита выделить группу, в которой он состоял в последний раз, а пойди найди нужного юнита среди одинаковых!) Зато в WarCraft'II можно было запомнить область карты - малополезное свойство, ведь в любую точку карты можно было попасть ткнув в нее мышкой.

В оконных интерфейсах нет и намека на возможность восстановить даже последнее выделение после его отмены, не говоря уж о более ранних (выделение восстанавливается только при откатке если с выделенным блоком что-нибудь делали). Запоминание точек для возврата в них реализовано в очень малом количестве редакторов - в МикроМире возможна только одна такая точка, при возврате в которую маркер переходит в ту точку, откуда произошел переход (для того, чтобы можно было вернуться обратно); в редакторе Word для восьмиразрядных машин Acorn'B/B+/Master (не имеет никакого отношения к MicroSoft) можно было пометить до восьми точек и некоторые операции осуществлялись с блоком текста, помеченным маркерами. А в оконных интерфейсах такой могучий механизм забросили... :-(

Совершенно неудовлетворительно разработана концепция ClipBoard (буфера обмена).

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

  • Разные программы работают с разными форматами данных; преобразование из одного формата в другой зачастую совершенно неоднозначно. Из Netscape Navigator в Word копируется только текст без шрифтов, зато с переводами строк там, где они были визуально; Internet Explorer гораздо лучше интегрирован с MS-Office, но попробуйте загрузить в Explorer страницу, скопировать в Word, сохранить на диск, а потом сравнить - Word внесет от себя много нового! Домашнее задание: попробуйте вставить через буфер Web-страницу в Excel и сообщите мне о результате. :-)

  • При копировании новой порции в буфер старое значение пропадает. Мне говорили, что можно как-то сохранять историю буфера и даже редактировать его содержимое, но показать не смогли.

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

Выбор из пунктов меню может показаться легче, чем запоминание команды, но только до тех пор, пока этот выбор ограничен некоторым разумным пределом или очень хорошо структурирован. Хорошо структурированных систем я в своей жизни почти не встречал - наверно, просто очень мало вещей легко поддаются структуризации, а непомерно распухшие древовидные списки делают поиск нужного мне пункта просто мучительным. Конечно, если я сам создавал это дерево и уже долго работаю с ним, то я буду легко ориентироваться в нем; но что делать, если я должен что-то сделать на чужом компьютере? Заставить хозяина стоять рядом? Таскать всюду с собой трехкилограммовый notebook? Конечно, есть такие решения, как smart-card для Network Computer (проект фирмы Oracle) или Newton Message Pad (фирма Apple), которые всегда с хозяином и не оттягивают карман, но это пока дело будущего.

Сложность меню определяется приложением. Если программа плохо спроектирована, это ее беда, а не беда оконного интерфейса.

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

Программист прав - эти пункты по смыслу надо объединить в некоторый содержащий их контейнер. Виноват интерфейс, который неудобно для пользователя работает с древовидным представлением информации. Тема древовидного представления информации вообще заслуживает отдельной статьи.

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

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

Можно подумать, что в текстовых приложениях нет подменю.

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

Ну а чтобы вбить последний гвоздь в гроб древовидного представления данных рассмотрим, как бы выглядел поиск это статьи, если бы ее URL w3.misa.ac.ru/prof/literat/antiwind.htm наряду со всеми другими URL был представлен в единой древовидной системе. Начнем поиск от корня.

  • В системе DNS есть шесть "организационных" доменов и около 250 доменов стран. Тут выбор легкий - либо в одном из организационных (скорее всего, в "org" или в "edu"), либо в домене России (хотя еще не исключен вариант домена Советского Союза). Надеюсь, Вы попадете правильно, потому что если ошибетесь, то вряд ли найдете искомое до конца жизни.

  • Я не знаю, сколько точно доменов в зоне "ru"; их там, конечно, меньше, чем в зоне "com", но тоже очень немало! На выбор - "org", "ac" и "msk".

  • Если первые два раза вы попали, то теперь попробуйте догадаться, что "misa" означает "Moscow Institute Steel Alloys", и что сотрудник металлургического института занимается вопросами интерфейсов.

  • На официальном сервере МИСиС "www", конечно, есть ссылка на то, что Internet-отдел имеет собственный сайт "w3", но попробуйте догадаться, что моя директория названа по моему прозвищу детских времен "профессор"!

  • Дальше можно просто поискать по директориям файл с подходящим именем - по счастью, он назван не аббревиатурой из первых букв названия (да еще переведенного на английский язык), а имеет в имени узнаваемый кусок слова "windows" - "окна".

Итак, я надеюсь, всем очевидно, что древовидная схема представления информации годится только когда объектов в ней не слишком много, в противном случае абсолютно необходима другая система навигации, а древовидная файловая система годится лишь для хранения информации и быстрого доступа к ней. (Могу привести пример того, как Proxy-сервер хранит свой кэш - в 14-символьном имени записывается шестнадцатиричный номер файла, первые два символа образуют имя директории, еще два - имя поддиректории, остальное - имя файла, а соответствие кэшированного URL номеру определяется по специальному файлу.)

А разве не для этого служат рубрикаторы Internet?

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


Вообще сложность построения системы визуального отображения информации проистекает непосредственно из виртуальности информации. В обыденном понимании виртуальность - это беготня по лабиринтам и стрельба по монстрам в стиле таких 3D-shooter'ов как Doom, Quake и т.п., но на самом деле эти игры как раз пытаются хотя бы в зрительном и звуковом аспекте максимально приблизиться к реальности, а виртуальность гораздо сложнее. В реальном мире действуют законы сохранения - каждый предмет может быть изменен или перемещен; в виртуальном мире мы имеем дело с информацией, которую можно изменить и скопировать. Реальный предмет можно скопировать путем изменения другого предмета; информацию можно перенести скопировав ее на новое место и уничтожив (путем изменения) на старом. Все становится простым и понятным если вспомнить, что информация на самом деле не существует сама по себе, а хранится на материальных носителях.

Очевидно, что в двух одинаковых книгах ровно столько же информации, сколько в одной - копирование не создает новой информации. Даже если книги различаются - имеют разный формат, сделаны из разных материалов и текст набран разным шрифтом - но содержат идентичный текст, то они содержат одну и ту же информацию. Мало кто задумывается над тем, что когда для редактирования файла его загружают в редактор, на самом деле в оперативной памяти создается копия файла, лежащего на диске. А при загрузке WWW-страницы по Internet вообще создается несчетное количество копий:

  • исходный файл лежит на диске сервера;

  • для передачи его по сети HTTP-демон (программа, осуществляющая WWW-сервис) загружает файл в оперативную память (если файл достаточно большой, то его могут загружать и отправлять по кускам);

  • фрагменты файла некоторое время хранятся в памяти всех IP-маршрутизаторов по дороге и затираются лишь по мере того, как эта память требуется для чего-то другого;

  • еще одна копия файла хранится в оперативной памяти и/или на диске машины, где запущен браузер, а также всех кэширующих Proxy-серверов;

  • и наконец, фрагмент файла, помещающийся на экране, отображается для визуального восприятия его пользователем.

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

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

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

Вернемся к оконному интерфейсу.

Да, мы слишком отвлеклись.

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

С летательными аппаратами произошла обратная метаморфоза: у птиц и несущим элементом, и движителем являются крылья, а у самолетов, которые давно превзошли птиц по скорости и высоте полета, а также по грузоподъемности, крылья - несущий элемент, а движитель - винт или реактивное сопло. У вертолета обе функции совмещены в одном элементе, но это не крылья, а винт. Как мы видим, для создания высокоэффективной системы отнюдь не всегда надо копировать существующие схемы. Вам это очевидно? А вот создателям интерфейсов это, похоже, абсолютно непонятно!

Посмотрим на файловое представление информации в DOS и Windows:

  • имеются логические диски (на самом деле не диски, а файловые системы; в DOS им присваиваются обозначения "A:", "B:", "C:" и т.д.; в Windows'NT они имеют имена);

  • на каждом логическом диске есть неудаляемая корневая директория;

  • в директории содержатся поддиректории (которые в свою очередь могут иметь вложенные поддиректории) и файлы;

  • у каждого логического диска есть такие параметры как тип (жесткий диск, дискета, CD-ROM, сетевой диск), объем, количество свободного места и др.

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

Каждый документ обычно представлен отдельным файлом, хотя есть исключения типа почтовых ящиков, которые обычно представлены двумя файлами (собственно ящиком и индексным файлом) и содержит внутри себя много писем.

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

А в новом интерфейсе, появившемся в Windows'95, файловая система еще больше утратила связь с реальностью. Посмотрим, как она организована (чуть подредактированный слепок с реального компьютера):

  • Рабочий стол
  • Мой компьютер
  • Диск 3,5 (A:)
  • System (C:)
  • CD-ROM (D:)
  • Принтеры
  • Панель управления
  • назначенные задания
  • Internet Explorer
  • Сетевое окружение
  • Norton Protected Recycle Bin
  • Портфель
  • Очень интересно: оказывается, мой компьютер находится внутри рабочего стола (или на нем)! Принтеры оказались на одном уровне с панелью управления, хотя они есть и внутри панели управления! Internet Explorer и мусорная корзина равноправны моему компьютеру (находятся на одном уровне)! Но я четко знаю, что все это (кроме, пожалуй, сетевого окружения) хранится на диске C:!!! (Под "принтерами подразумеваются драйверы принтеров и программа их настройки.)

    Гораздо логичнее организована World Wide Web, где гипертекстовые ссылки отделены от файловой системы и совершенно не обязаны составлять древовидную структуру. Вообще пора скрыть файловую систему от пользователя и даже от многих программ и предоставлять доступ в терминах не файлового доступа, а доступа к данным - это освобождает программиста от необходимости разбираться с форматом хранения данных в файлах и позволяет разнести вычисления на разные машины в архитектуре "клиент-сервер".

    Проблемы организации файловой системы, согласитесь, достаточно далеки от проблем оконного интерфейса

    И да, и нет. Проблема организации файловой системы действительно слабо связана с интерфейсом пользователя, но вот проблема представления файловой системы пользователю - проблема интерфейса. У программиста есть два пути:

    1. дать пользователю доступ к системе в том виде, в каком имеет доступ программа просмотра, и в этом случае пользователь должен копаться в особенностях файловой системы;

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

    Любое промежуточное решение только породит проблемы: пользователь будет вынужден иметь дело с файловой системой когда ему этого совсем не нужно, а когда потребуется - доступ будет затруднен.

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

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

    Это сколько рядовому пользователю придется запоминать? В некоторых особо сложных программах (да хотя бы Word) toolbar может содержать до тридцати иконок. Давайте рассмотрим, насколько очевидными являются иконки Netscape Communicator для Windows'9x/NT (я выбрал его чтобы не говорили, что я ругаю только MicroSoft):

    • стрелки влево и вправо - "Back" и "Forward":
      достаточно очевидно для европейца, который читает слева направо, но не для еврея с арабом (справа налево) или китайца (сверху вниз);

    • закрученная стрелка - "Reload":
      совершенно неочевидно!

    • избушка - "Home":
      для меня "домой" означает "в мою городскую квартиру"; а к избушке я бы скорее применил слово "house" ("здание"), не имеющее отношения к действию этой кнопки.

    • фонарик - "Search":
      в Windows принято при поиске шарить фонариком в потемках - именно "принято", т.е. "привычно", но совсем неочевидно;

    • дорожный указатель - "Обзор", ссылка на guide.netscape.com:
      обозревать можно что угодно - совершенно неочевидно!

    • принтер - "Print":
      очевидно, только если знать, что загогулина сверху означает лист бумаги, на котором печатают - принтер, которым я пользуюсь, выглядит совершенно иначе!

    • замок - "Security" (информация по защите):
      более-менее очевидно;

    • светофор с горящим красным фонарем - "Stop":
      лично я никого еще не останавливал светофором - скорее уж размахивая руками; кстати, можно было бы взять из военного учебника сигнал флажками - он более очевиден, а заодно пользователи освоят этот сигнал на случай службы в армии; :-) к тому же тычок мышкой может означать как "применить красный свет", так и "сменить его на другой".

    Итак, все до одной иконки менее очевидны, чем подписи под ними.

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

    В какой-то степени опровергая себя, признаюсь, что я привык работать когда браузер отображает только картинки без подписей. Но я действительно выучил значение картинок, а подписи занимают экранное пространство (лучше бы их располагали не под картинками, а рядом); а вот у тех, кто привык к другому браузеру или хотя бы к другой версии Netscape, постоянно возникают трудности, особенно когда я подсказываю "Нажми Reload", а меня переспрашивают "А где он?".

    Обычно пользователь запоминает расположение иконок, и ориентируется по их расположению.

    Не могу отрицать полезности фиксации элементов управления; но ведь гибкость оконных интерфейсов воспевается как их главное преимущество - окно может быть расположено в любой части экрана! Еще в DOS многие программы повадились сами сохранять конфигурацию чтобы в следующем сеансе работы стартовать как будто работа не прерывалась; но там хоть в большинстве случаев можно было отключить такую возможность (пример - Norton Commander и его клоны). Современные оконные системы норовят запомнить все что только можно. Чтобы отучить от этой дурацкой привычки Netscape Navigator, я ставлю атрибут "ReadOnly" на файл netscape.ini; а вот некоторые программы умудряются пробивать даже этот атрибут. Program Manager от Windows'3.11, обнаружив "ReadOnly" на файле progman.ini, выдает окно с сообщением о том, что он, вот ужас, не сможет сохранить изменения, и ждет нажатия кнопки "Ok", и до тех пор, пока пользователь не нажмет кнопку; при этом не запускаются никакие программы из группы AutoStart или указанные в командной строке как аргументы win.com.

    Многие меню, тулбары и прочие средства навигации, не говоря уж о списке файлов в любом их диспетчере, могут в любой момент измениться - какая уж тут может идти речь об ориентации по положению на экране!

    Чтобы вызвать любой объект по имени, нужно держать в памяти имена всех объектов!

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

    Представление объектов в графическом виде всегда будет вторично по отношению к текстовому. Начнем с того, что имена можно упорядочить по алфавиту, а как упорядочить картинки? А если надо объяснить человеку, куда нажать, то как обрисовать картинку - перечислять содержимое? Все равно у каждого объекта будет имя и это имя придется запомнить, а иконка - лишь вспомогательное средство.

    Но ведь довольно часто информация представляется в виде пиктограмм. Например, дорожные знаки, указатели.

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

    Когда приходится работать в Word'е, локализованном для страны с незнакомым языком, все пункты меню непонятны, а картинки - те же. А иногда системный фонт нерусифицирован, так что прочитать пункты меню не удается.

    Хотел бы я посмотреть, как пользователь будет читать сообщения программы в иноязычном продукте!

    А невозможность оперативно сменить системный фонт (лучше всего - только для данной программы, хотя можно и для всей системы, только, желательно, временно - до перезагрузки) есть мерзкое свойство персональных компьютеров. Любой компьютер (любая операционная система), изначально рассчитанная на работу (одновременную или по очереди) многих пользователей, должна позволять такие операции: Unix позволяет каждому пользователю иметь собственные настройки X11 и даже несколько X-серверов; Acorn позволяет загружать шрифты в дополнение или на замену, но при выключении система возвращается в исходное состояние.


    В конце концов, "указать и нажать", а также "перетащить и бросить" можно и без окон. Point&click реализован еще в Norton Commander и Norton Utilities, а также во всех программах, использовавших мышь в качестве основного устройства ввода (типа PaintBrush) задолго до появления оконных систем. Drag&drop из одной полноэкранной задачи в другую можно делать, если во время переключения есть куда положить (например, в Newton - на поля документа) или если можно переключить задачу, не бросая то, что тащишь.

    А разве Norton Commander и ему подобные программы не являются оконными?

    Ну, если рассматривать любое выпадающее или всплывающее меню как окно, то многие программы содержат в себе оконную оболочку. Библиотеки типа Turbo Vision позволяет программисту писать программы с оконным интерфейсом, причем как в текстовом экранном режиме, так и в графическом. И легко заметить, что чем более "оконной" делается система, тем неповоротливее и прожорливее к ресурсам она получается, а увеличение количества "наворотов" делает систему неудобной для пользования.

    Впрочем, я бы поостерегся с ходу называть любую программу, которая восстанавливает содержимое экрана после себя или после другой программы, "оконной". Гораздо эффективнее, чем окна, разбиение экрана на кадры (frames). В качестве двух кадров фиксированного размера можно рассматривать Norton Commander. На кадры разбивает экран и PaintBrush (в отличие от него PictureManager фирмы Cognitive Technologies держит панели инструментов в виде отдельных окон). И неподвижные меню больше похожи на кадры, чем на окна. Кадры часто используются в оконном интерфейсе, использование кадров вместо окон делает программу более удобной и эффективной.

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

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

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

    • Нигде не реализована смена схемы разбития:
      "горизонтальное"
      -|--|--|--|-
      -|--|--|--|-
      -|--|--|--|-
      "вертикальное"
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      -|-
      "смешанные"
      -|--|- -|--|-
      -|--|-
      -|--|-
      -|--|-
      -|-
      -|-
      -|-
      -|-
      -|--|--|-
      -|-|- -|-
      -|-
      -|-
      -|-|-

      Это легко объяснимо: трудно наглядно указать, как именно мы хотим расположить фреймы. Операция, элементарно выполняющаяся редактированием frameset'а, становится невообразимо тяжелой при попытке реализовать ее перетаскиванием.

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

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

    • Чрезмерно увлекающиеся фреймами Web-мастеры часто делают фреймы с неподвижными границами - на экране другого разрешения и/или с другим размером шрифта часть содержимого может уйти за границу фрейма и ее оттуда никакими силами не достанешь! :-(

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

    При работе с сенсорным экраном рука будет заслонять часть изображения.

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

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

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

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

    Кроме того, я не чувствую, когда мышь пересекает какую-либо границу, нарисованную на экране, а вот клавиатуру я чувствую пальцами. Говорят, начат выпуск мышей с обратной связью - при попадании курсора мыши на объект мышь будет как-то реагировать (например, замедлять движение), но такие мыши пока (конец 1999) весьма недешевы и что-то не пользуются массовым спросом.

    Можно подумать, что рисуя пером на экране или двигая курсор с клавиатуры можно почувствовать границу на экране.

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

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

    Особые неудобства вызывает двойной щелчок (double-click). Как правило, человек не может напрячь отдельную мышцу, напрягаются в той или иной степени все соседние. Нужно обладать поистине акробатической ловкостью, чтобы никогда не сдвигать мышь между нажатиями кнопки, а это приводит к тому, что вместо двойного щелчка получаются два одинарных, что совсем не одно и то же. Проще после выделения нажать на [Enter], но надо переносить руку с мыши на клавиатуру, а это неудобно.

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

    Но ведь оконные системы совершенствуются.

    На мой взгляд, они скорее деградируют. Если в Windows'3.11 я мог вызвать окно Program Manager (диспетчера программ), чтобы запустить новую программу, то в Windows'95 для этого приходится либо блуждать по дереву меню кнопки "Start" (в русской версии - "Пуск"), либо закрывать все открытые окна, чтобы добраться до ShortCuts (выложенных на поверхность стола иконок). Это неудивительно, ведь интерфейс Windows'95 скопирован с Macintosh'86.

    В Windows'3.11 Program Manager позволяет открыть все свои окна и расположить их так, чтобы они не перекрывались - как бы разбить пространство на кадры. При этом я вижу все иконки программ, но они разбиты на группы, причем переход между иконками осуществляется стрелками, а между группами - 'Ctrl+Tab'; "мозаика", адаптированная к числу иконок в каждом окне, фактически эквивалентна разбиению главного окна на фреймы. Program Manager в Windows'3.11/NT3.x гораздо лучше отображает двухуровневое дерево ссылок на программы, чем средства Windows'9x/NT4.0, где не предусмотрено средств группировки иконок на Рабочем столе - вот вам и подтверждение тезиса о деградации.

    Такое относительное новшество, как модальные окна, причиняет немало неудобств (и в этом со мной согласны даже самые яростные критики). Если оконная система предназначена для того, чтобы держать перед глазами одновременно несколько документов, то почему нельзя подвинуть родителя модального окна, пока не закроешь это модальное окно? Модальные окна как были в интерфейсе Windows'3.11/NT3.x, так без изменений перекочевали в Windows'9x/NT4.0.

    При том, что версии графических операционных систем пекутся как блины, побуждая пользователей тратить на инсталляцию и настройку больше времени, чем на полезную работу, их создателям и в голову не приходит оглядеться вокруг и внести усовершенствования, которые давно есть у соседей. Пример - операции "Load" и "Save as" в MicroSoft Windows (как в 3.11, так и в 95/NT) выдают окно неизменяемого размера, при том, что в Solaris это окно можно легко растянуть и просматривать не по восемь файлов, а сколько уместится на экране. Прокрутка здесь мало помогает, ибо глазами человек двигает гораздо быстрее, чем руками.

    В Windows'3.11 этот мини-FileManager не позволяет ни создать директорию, ни стереть или переименовать файл - только перейти в директорию и выбрать нужный файл; в Windows'95/NT это исправлено. Зато появился ExchangeClient, а в нем "правила", определяющие, что делать с тем или иным письмом. Эти правила состоят из условной части "Если в строке "From:" содержится то-то и в строке "To:" содержится то-то, а в теле письма то-то..." и действия "Стереть", "Переместить в папку" и т.п.

    • эти "правила" показываются по пять штук, и окно, естественно, не растягивается.

    • При наличии в строке "From:" имени "правила" не реагируют на адрес.

    • Отсутствует отладчик, позволяющий выяснить, какое правило засунуло письмо не туда, куда мне нужно.

    • Невозможно экспортировать "правила" в текстовый вид и импортировать обратно, чтобы видеть их несколько сразу, работать с ними в моем любимом редакторе или натравить на них написанную мной программку.

    • Очень неудобно копировать из заголовков в редактор правил - Окна просмотра заголовков и редактирования правил не открываются одновременно! Точно также нельзя открыть два окнА редактирования правил; но это хотя бы обусловлено модальностью этого окнА, а родители окон просмотра заголовков и редактирования правил независимы! В результате приходиться мотаться по кругу: открыл окно просмотра заголовков - скопировал в буфер - закрыл окно просмотра заголовков - открыл окно редактирования правил - вставил из буфера - закрыл окно редактирования правил - ...

    • Невозможно построить разветвляющуюся систему "правил" - среди действий нет операций изменения последовательности просмотра списка "правил" кроме "Закончить просмотр списка правил".

    Другой пример - автоматическое "всплывание" активного окна наверх во всех Windows'* и многих реализациях X-windows. Поверх активного окна могут удержаться только те, кто специально этого хочет - из таких программ я могу вспомнить только "clock" ("часы"). В то же время в Solaris можно активизировать и двигать окно, не вызывая его наверх - это свойство как раз полезно в тех случаях, когда надо видеть одно окно, а работать в другом.

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

    Хорошо, но не в командной же строке мне работать?

    Большинство современных пользователей работают под различными версиями MS-Windows. Для них графическая оконная система кажется единственной альтернативой кошмару командной строки DOS. На самом деле это не так. Не говоря уж об аналогичных, но более совершенных системах типа Apple Macintosh, Acorn RiscPC и X-Windows для Unix (каждая из которых в своей области намного превосходит MS-Windows), есть и другие концепции пользовательского интерфейса. Это командная строка Unix и графический (но не оконный) интерфейс Apple Newton Message Pad.

    Что касается командной строки, то даже в Windows'NT такие утилиты работы с Internet как ARP, Ping, TraceRoute, NSLookUp (не говоря уж о Telnet) реализованы в виде эмуляции текстового экрана в окне и запускаются с командной строки, хотя многим из них так и просится графический интерфейс. Интерфейс Windows'95 сильно проигрывает оттого, что в нем нет элементарной операции "вызвать командную строку", а то, что есть - "Start"/"Run" - долго вызывается, а иногда почему-то спрашивает аргументы команды. Из "Start"/"Run нельзя подать команды 'dir' и 'cd', нельзя подать несколько команд (как это делается в Unix через точку с запятой), и вообще эта система, на мой взгляд, совершенно неудобна.

    Вообще Internet, пошедший от Unix, унаследовавший многие его недостатки и достоинства, сильно привязан к текстовым форматам. Так FTP-клиенты, оформленные в виде, аналогичном FileManager, все равно посылают серверу стандартные команды, получают от него текстовые ответы и выводят этот диалог в специально отведенном месте своего окна.

    Ну и как же можно сделать командную строку удобной?

    Acorn OS, реализованная еще в 1982 году на восьмиразрядных машинах, позволяла легко скопировать в командную строку любую последовательность символов с экрана, причем в графическом режиме происходило распознавание символов (правда, распознавалось только полное совпадение с оригиналом). При редких обращениях к файлам, малом количестве файлов и достаточно продуманной системе команд это давало вполне приемлемый комфорт работы в командной строке. Поэтому все программы, в том числе и редакторы, имели выход в командную строку, более того - собственные команды "загрузить файл", "записать файл", "отформатировать текст" воспринимались с той же командной строки, и это было вполне удобно. Даже секретарши уверенно работали в этой среде, тем более что все часто выполняемые последовательности команд легко вызывались скриптами.

    Часто используемый в Linux командный интерпретатор bash (Bourne Again SHell) пригодный, впрочем, и для других Unix'ов, позволяет вызвать ранее введенную команду с аргументами и редактировать ее, перемещаясь стрелками. Такие же средства предоставляет командный интерпретатор Windows'95/NT, а также альтернативные командные интерпретаторы для DOS. Широко известный советскому пользователю Norton Commander и его аналоги помимо этого позволяют также скопировать в командную строку имя файла, а некоторые из аналогов - еще и путь к текущей директории. За это, кстати, их, вопреки ожиданиям MicroSoft, держат на машинах с Windows - командная строка, все-таки, на порядок более мощное средство, чем мышь, тыкающая в иконки.

    Командные интерпретаторы в Unix'ообразных системах также, как правило, умеют дозаполнять частично введенные строки (это с них скопированы аналогичные функции в 4dos и cmd.exe Windows'NT). zsh - соптимизированный для интерактивной работы вариант bash - позволяет гибко настраивать подобное заполнение. Ему можно объяснить, например, что аргументы команды mkdir или cd надо заполнять только именами директорий, а не директорий и файлов, как обычно, а аргумент команды mail, если ему не предшествует никакой ключ - именем пользователя.
    Artem Chuprina

    Интересная командная строка у маршрутизатора Cisco. Многие команды имеют тьму аргументов; запомнить их все очень сложно, поэтому используется контекстная подсказка: набрав часть аргументов, можно нажать "?" и получить список возможных продолжений (аргументов) с пояснениями их значений, а в командной строке снова будет набранное перед нажатием вопроса. (Повтор предыдущих команд, как в bash, разумеется, тоже есть.)

    Я заметил, что Вы постоянно противопоставляете плохо сделанный оконный интерфейс хорошо сделанной командной строке.

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

    И что же, все операции можно и нужно делать с командной строки? Даже ...

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

    Другой пример - редактор МикроМир, написанный ребятами из МГУ и распространяемый бесплатно. При размере менее 90 KB он позволяет работать с тремя независимыми буферами - поточным, строчным и прямоугольным; использовать имя файла в тексте как гиперссылку, т.е. легко перейти к этому файлу, запустить программу по его расширению и др.; сделать буквы большими, маленькими, русскими или латинскими (особенно полезно, если они набраны не в том регистре); работать в режиме таблиц, ограниченных псевдографикой; сортировать строки. Особенно радует, что можно свободно переносить текст между текстом, строкой поиска, строкой замены и командной строкой, а также то, что ранее введенные значения этих строк автоматически запоминаются и их можно легко вызвать. Разумеется, некоторые нелогичности есть и у МикроМира, тем более что новых версий не выходило с 1984-го года.

    А текстовые процессоры, WWW-навигаторы, графические редакторы наконец? Они тоже должны управляться с командной строки?!!!

    Нет, хотя запускать их можно и оттуда. Но вот выполняться они вполне могут в полноэкранном режиме, а не в оконном. Все равно даже полного экрана им мало.

    А если мне надо держать перед глазами два документа? Да еще в разных программах?

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

    Специалисты фирмы Xerox, когда разрабатывали оконный интерфейс ...

    А разве оконный интерфейс был разработан фирмой Xerox? Она же не имеет никакого отношения к компьютерам!

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

    В какой-то степени эти два режима - работы с программой и просмотра списка программ - реализованы в виде полноэкранного режима задачи и Панели Задач (taskbar). Первый недостаток такого подхода в реализации Windows'9x/NT в том, что Панель Задач оформлена в совершенно ином стиле, чем задачи - она расположена на краю экрана (обычно внизу) и либо присутствует постоянно, либо появляется при подходе курсора к краю экрана. Гораздо лучше был реализован Список Задач в Windows'3.11 - он появлялся в виде окна в центре экрана. Если бы еще это окно могло менять свой размер в зависимости от количества задач - ему цены бы не было! Существенным недостатком обоих списков задач является то, что в них отражается слишком мало информации, да к тому же это зачастую не та информация, которая нужна пользователю. Например, при запуске нескольких окон WWW-браузера мне хотелось бы в списке задач видеть, что происходит с ними, какая страница закачалась, а какая еще нет; вместо этого в списке задач видно только заголовки задач.

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

    Впрочем, в той же самой лаборатории PARC уже разрабатывается интерфейс Hyperbolic Tree, не имеющий ничего общего с окнами. Возможно, они прочитали черновой вариант этой статьи, опубликованный на WWW-сервере.

    Ну и в чем же суть этого интерфейса?

    Начну издалека: как известно, глаза человека охватывают почти 180° по горизонтали; при этом около 30° составляет "рабочая область", в которой острота зрения максимальна, а к краям чувствительность зрения падает - отсюда понятие "боковое зрение". Монитор компьютера спроектирован так, что вся его рабочая область оказывается в центральном поле зрения. Для игр типа "Doom", "Duke Nukem 3D", "Quake" это очень неудобно - человек оказывается "зашоренным" (от слова "шоры" - что-то типа очков, надеваемых лошади, чтобы та не видела ничего по сторонам и не отвлекалась); в то же время игроку надо иметь максимально естественное зрение. Частично этого можно достичь применением "виртуального шлема", экран которого охватывает все поле зрения игрока.

    Боковое зрение, в поле которого находятся те документы, с которыми пользователь в данный момент не работает, было проигнорировано создателями оконных систем; возможно, у них были большие мониторы. В любом случае тот документ, с которым я работаю, должен занимать подавляющую часть "рабочей области", а остальные документы должны быть вытеснены "на периферию". Частично это реализовано в виде "панели задач" в Windows'95/NT, но она оказалась слишком негибкой - если иконки на "рабочем столе" и в меню "Start" можно распределить по папкам (директориям), хотя это и не самое удобное, то в "панели задач" они расположены строго в порядке их запуска. К тому же в "панели задач" отображаются именно задачи, точнее - программы, чей запуск их породил; гораздо логичнее было бы отображать документы - иконки, олицетворяющие задачу, должны содержать не рисунок задачи (например, стилизованную букву "W" для редактора Word), а внешний вид документа (той части, которая видна в рабочем поле редактора), уменьшенный до размеров иконки. То же самое, кстати, относится и к отображению документов-файлов в FileManager - желательно изображать их не типом обрабатывающей их программы, а видом титульной страницы.

    Ну, а сама идея "Hyperbolic Tree" - в том, что информация представлена в виде дерева (графа, у которого между любыми двумя вершинами имеется ровно один путь) без выделенного корня; объекты, с которыми работает пользователь, представляются вершинами дерева, а связи между ними - ребрами; в качестве корня принимается тот объект, с которым работает пользователь, а остальные расположены вокруг него, причем чем дальше от выбранного корня по дереву расположен объект, тем дальше от центра он располагается и менее детально отображается.

    Для интересующихся дам ряд ссылок на статьи:

    Честно говоря, я не жду от Hyperbolic Tree ничего сверестественного - скорее всего, эта идея будет долго эволюционировать и обмениваться с другими формами отображения и структурирования информации, прежде чем станет пригодной к использованию, так что от исходной формы в ней мало чего останется. Тем не менее в Hyperbolic Tree сделан важный шаг - подробность представления документа не двуступенчата, как в оконных системах ("свернуто" и "развернуто"), а плавно меняется в зависимости от удаленности от "фокуса внимания пользователя". Кстати, уже сейчас можно начать критиковать Hyperbolic Tree за то, что в ней предусмотрен только один "фокус внимания"; а если пользователю нужно сосредоточиться на двух и более объектах?

    Но все это можно делать и в оконной системе. Зачем же от нее отказываться?

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

    Я говорил, что прожорливость к ресурсам не является главной причиной; я имел в виду только то, что оконные системы неудобны сами по себе, но экономия ресурсов - тоже немаловажная вещь. Обратите внимание: как только мы отказываемся от текстового режима и переходим на графический, немедленно в два, а то и более раз вырастают потребности в памяти. Например, Unix-сервер (FreeBSD или Linux) можно запустить на 4 MB памяти (правда, это будет весьма медленный сервер), а Windows'NT'Server можно запустить никак не меньше чем на 16 MB (и работать будет не лучше, чем Unix на 4 MB). На 8 MB можно запустить W'95, а на 4 MB - W'3.11, но при этом мы лишаемся и вытесняющей многозадачности, и разграничения доступа к файлам на уровне операционной системы, и всех остальных свойств, которые должны присутствовать в серверной операционной системе.

    В этом смысле очень интересно сравнить взаимодействие программы с WindowManager'ом и взаимодействие X-терминала с хостом. Если компьютер с принтером можно рассматривать как мини-сеть, то почему бы взаимодействие программ не рассматривать как клиент-серверное? Так вот, X-терминал посылает сообщения хосту о каждом событии - тычке мышкой, нажатии кнопки, необходимости перерисовать окно. А вот HTML/Java-терминал тривиальные случаи (перерисовку, прокрутку, ввод символов в поля ввода) обрабатываются встроенной программой (браузером), для не очень тривиальных в составе страницы есть программки на Java и JavaScript, а самые нетривиальные, требующие новых данных, передаются на WWW-сервер. Примерно такую же модель давно надо было реализовать и в оконных системах. Я не уверен, что при выполнении задач, ядра OS и драйверов на одном процессоре нужен промежуточный слой программ обработки "не очень тривиальных случаев", хотя для асимметрично-мультипроцессорной архитектуры с медленной передачей сообщений, каковой является сеть, это очень удачное решение. Примерно такая схема, насколько я знаю, была реализована в RiscOS - задача может передать окно модулю, который берется за обслуживание сообщений к этому окну. При этом окно должно быть описано в определенных терминах - здесь картинка, здесь текст, а здесь кнопка - и задача, создавшая окно, будет обрабатывать только то, что не удается описать в рамках понимаемых этим модулем терминов; впрочем, туда были включены все наиболее часто используемые элементы. К сожалению, этот способ сделать оконные программы более компактными так и не перекочевал в другие операционные системы.

    Объектно-ориентированное программирование позволяет не обрабатывать те события, которые не интересуют программу.

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

    А пока WindowManager не умеет сам обрабатывать такие события, программа на объектно-ориентированном языке все равно будет обрабатывать все события; даже если программист проигнорировал какой-либо тип события, компилятор сам добавит "стандартный обработчик", бессмысленно пожирающий ресурсы машины.

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

    А для многих задач коллективной работы с каким-либо набором данных зачастую достаточно мощного компьютера, к которому подключены дешевые текстовые терминалы. Существенное преимущество такого подхода - резкое снижение стоимости всей системы при большом рабочих мест и снижение загруженности сети. (Еще меньше загружают сеть HTML- и Java-терминалы, но они сложнее и поэтому дороже.) Вдобавок SQL-клиент, выполняющийся на одной машине с SQL-сервером и отображающий результаты своей работы в виде терминальных управляющих Escape-последовательностей либо в виде HTML, гораздо быстрее осуществляет транзакции, чем SQL-клиент, выполняющийся где-то в сети. У текстового терминала, кстати, гораздо меньше уровень электромагнитного излучения и выше качество изображения, но об этом мало кто задумывается.

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

    И как это должно выглядеть?

    Допустим, что ширина экрана - 640 пикселов; самые узкие символы - восклицательный знак, точка, пробел - шириной три пиксела; значит, система должна быть рассчитана на 213 символов в каждой строке. Допустим, в строке оказался широкий символ, занимающий девять пикселов, а остальные - пробелы; это значит, что будет отображено только 210 пробелов, а остальные символы не будут отображаться на экране вообще.

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

    Хорошо, это все количественные различия. А есть что-нибудь более существенное?

    Ну, для системного администратора, на мой взгляд, "наглядное графическое представление данных" просто опасно - освоивший технологии "укажи и нажми", а также "перетащи и брось" берется за управление системой, не освоив основ ее функционирования. Хуже того - очень многие начинают путать интерфейс представления данных с самими данными. Это не страшно до тех пор, пока система функционирует в рамках, описываемых интерфейсом, т.е. в пределах того, что предусмотрено ее создателями. Но, как известно, катастрофы не требуют планирования, а любая нештатная ситуация потому и нештатная, что не предусмотрена создателями системы (иначе система сама бы справилась). При этом я сошлюсь на PC Week 12(86) от 1..7 апреля 1997, статья Леонида Миронова "Нужен ли ГИП(GUI) для серверной ОС?".

    Если Вы настраиваете IP-маршрутизатор, никакой графический интерфейс не позволит Вам обойтись без знания таких вещей как "номер сети", "маска", "шлюз"; настройка DNS (сервера доменных имен) требует знать, что обозначают записи MX, NS, A, PTR, HS-INFO; а борьба с сообщением "No access" ("недоступно") требует разбираться в правах доступа. И "интуитивно понятный интерфейс", даже с "контекстной подсказкой" мало поможет, если нет фундаментальных знаний.

    Установка атрибутов доступа каким-нибудь SecurityManager (менеджером безопасности) ничем не поможет, если в системе есть хоть один способ доступа в обход этих атрибутов, в то время как все программы будут наглядно показывать, что система полностью закрыта от нежелательных лиц. Как можно определить, что в системе настежь открыта "задняя дверь"? Только детально разбираясь в "потрохах" системы, не полагаясь на сообщения привычных утилит, тем более что однажды проникший в систему злоумышленник вполне мог заменить эти утилиты на свои, которые никогда уже не скажут правды законному администратору.

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

    Ну, большинство пользователей работают все-таки не с ядерными реакторами!

    Да, но им тоже не помешает знать детали функционирования системы. Когда в 1987..1992 годах я работал на компьютерах фирмы Acorn, модель B+, я заметил прекрасное свойство операционной системы: системный вызов OSByte соответствовал команде *FX, т.е. команда

    
            *FX аргумент1 аргумент2 аргумент3
    
    
    с числовыми аргументами соответствовала ассемблерному коду процессора 6502
    
            LDA #аргумент1
    
            LDX #аргумент2
    
            LDY #аргумент3
    
            JSR OSByte
    
            
    правда, при этом нельзя было узнать, какие значения возвращает операционная система в регистрах A, X и Y :-(. Таким образом, можно было задать автоповтор клавиатуры; определить действие функциональных клавиш и стрелок; перенаправить ввод-вывод; настроить работу последовательного и параллельного портов, а также видеосистемы и многое другое. Граница между квалифицированным пользователем и программистом почти отсутствовала.

    DOS предлагает гораздо худшую модель: между командой

    
            MODE con RATE=r DELAY=d
    
    
    и ее ассемблерным аналогом
    
            MOV AX, 0305H
    
            MOV BL, 32-r
    
            MOV BH, d-1
    
            INT 16H
    
            

    уже нет такого однозначного соответствия. Однако пользователь легко может написать script или, как его называют в DOS, batch-файл (по-русски - пакет команд), который будет содержать команды, обычно подаваемые с клавиатуры. Пользователь может облегчить себе жизнь, но стать программистом ему будет гораздо труднее.

    А вот в системах с "менюшным" интерфейсом создать пакетные задания гораздо сложнее - между пользователем и программистом пролегает почти непреодолимая пропасть. Именно поэтому удобные пользовательские интерфейсы создаются людьми, которые прошли огонь, воду и медные трубы примитивной командной строки без средства редактирования, да еще в отсутствии удобных утилит - но чем удобнее созданный ими интерфейс, тем быстрее система перестает развиваться, впадает в стагнацию. Избежать застоя, насколько мне известно, удалось только Acorn и Unix. Acorn изначально разрабатывал комплексное решение, включающее сам компьютер и программное обеспечение (от ядра операционной системы до текстовых редакторов), зашитое в ПЗУ. Основную прибыль приносит продажа "железа", поэтому фирма оказалась заинтересована в расширении круга программирующих для этой платформы. ПО (как фирменное, так и независимых производителей) строится из независимых модулей, связанных протоколами вызовов. Наиболее популярные (часто используемые) модули включаются в ПЗУ следующих версий.

    Unix - уникальный феномен многих операционных систем для разных аппаратных платформ, объединенных общими стандартами. Несмотря на наличие нескольких семейств, таких как System V и BSD, а также множества диалектов типа QNX, Unix'ы сохраняют совместимость на уровне исходных текстов программ (откомпилированные программы не переносятся не только на другой процессор, но и на другой Unix, работающий на том же процессоре). Переносимость программ удивительна даже по сравнению с совместимостью разных версий одной операционной системы одной фирмы для конкретной платформы. Жизнеспособность Unix долгое время поддерживалась доступностью исходных текстов ядра и утилит; в последнее время исходные тексты коммерческих Unix'ов недоступны, но появились бесплатный FreeBSD (в противоположность платному BSDi) и "народный Unix" Linux. Жизнеспособность Unix поддерживается прежде всего конкуренцией среди разных групп программистов, каждая из которых стремится сделать свой Unix лучше других, а лучшие решения быстро перекочевывают во все другие реализации.

    Так что же, оконные системы обречены на вымирание?

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


    Виртуальные консоли реализованы в BSD, Linux, Interactive Unix, SCO Unix и Xenix для PC, AIX для POWER-PC; остальные я не проверял.

    Скрипты - интерпретируемые программы, задающие последовательность выполнения определенных действий, например, выполнения команд командной строки (Shell scripts в Unix, BAT-файлы в DOS) или диалога с удаленной системой (скрипты инициализации модема и входа в систему в UUPC).

    Linux был создан скандинавским студентом Линусом Торвальдсом, а затем дописывался всеми желающими. Свободно доступен как для некоммерческого использования, так и для коммерческих проектов.

    Неудобство, например, в том, что если я искал (через F7) слово в каком-либо файле, то после выхода из редактора или вьювера это слово безвозвратно забывается.

    МикроМир для DOS, Macintosh и Unix можно взять на FTP mech.math.msu.su/pub/mim/


    Оригинал этой статьи доступен на сайте автора: http://www.misa.ac.ru/prof/
    С автором можно связаться по e-mail: Dmitry.Karpov@misa.ac.ru



    Наверх Письмо Web-мастеру