| Центр Практичных Программ | "Этот мерзкий, неудобный, противоестественный оконный интерфейс" |
Вашему вниманию предлагается подробный анализ статьи Дмитрия Карпова, опубликованной на сервере www.webclub.ru. В противовес статье, данный анализ не ставит своей целью защиту оконного интерфейса, а является просто трезвой оценкой предлагаемого материала, способной указать на некоторое предвзятое отношение автора к оконным интерфейсам.
Текст самой статьи идет обычным текстом, наши коментарии - курсивом.
Дмитрий Ю. Карпов
Московский Институт Стали и
Сплавов
PostMaster
prof@misa.ac.ru
Мне не нравятся оконные системы. Даже не потому, что они медленно загружаются (есть такие, которые загружаются быстро), не потому, что жрут ресурсы машины (есть довольно экономные, по крайней мере по сравнению с остальными), не потому, что часто рушатся и требуют долгой нудной инсталляции (есть довольно стабильные и даже вообще зашитые в ПЗУ). Просто графический оконный интерфейс, по моему скромному мнению, - неудобный, в большинстве случаев ненужный, а часто просто вредный. И я могу доказать это;.. ну, по крайней мере попробовать доказать.
О чем идет речь в этом абзаце ? Автор указывает на некоторые недостатки, и тут же их сам и опровергает. Более того, все указанные "недостатки" на самом деле относятся не к интерфейсу, а к операционным системам.
Нельзя говорить об оконном интерфейсе, не затрагивая недостатков отдельных реализаций; более того, общие недостатки всех реализаций часто вовсе не являются непреодолимым недостатком оконного интерфейса. Не надо ждать от меня строгой последовательности, я не пророк и Бог не говорит из меня. Я лишь утверждаю, что значительную часть задач можно и должно решать на базе других, более простых средств. Речь идет о неудобстве и неэффективности оконного интерфейса вообще.
Посмотрите на свой экран: если Вы не являетесь счастливым обладателем 21-дюймового монитора и видеокарты с разрешением 1280*1024 (которые стоят в несколько раз дороже остальноого компьютера), то, я уверен, подавляющую часть времени его целиком занимает задача в полноэкранном режиме. Если Вы работаете с несколькими задачами, Вы переключаетесь между ними - но каждая из них все-таки будет занимать экран целиком. Впрочем, большой монитор покупают те, кому надо работать в графике высокого разрешения (полиграфия, картография, чертежные работы), а при этих работах не до многооконности - даже такого разрешения подчас моловато. Так зачем же нужны в полноэкранных задачах элементы оконного интерфейса, которые только отьедают драгоценное экранное пространство?
Да, в большинстве случаев пользователи действительно работают в полноэкранном режиме, с одной пограммой (документом), а в остальных случаях? Кроме того, автор видимо имеет в виду главные окна приложений, однако практически любое приложение имеет также диалоговые окна настроект, свойств и т.д. Ведь это тоже окна. Теперь о пространстве. На самом деле элементы оконного интерфейса занимают не так уж много места на экране. Далее в тексте статьи автор предлагает "альтернативное" решение в виде деление экрана на кадры. Но разве такое решение не будет занимать дополнительного места на экране.
Отнюдь. Достаточно посмотреть, сколько времени у пользователя уходит на то, чтобы красиво расположить окошки, чтобы стало понятно - оконный интерфейс не только не облегчает работу, но и забирает рабочее время, которое могло бы быть потрачено с большей пользой. Поиск в ворохе набросанных на экране окон или среди сваленных в беспорядке иконок - отличный способ убить впустую значительную часть рабочего времени. Почти вся полезная работа производится в полноэкранном режиме какой-либо программы.
Конечно, если человеку нравится заниматься "красивым" расположением окон на экране, ничто его от этого не отучит. Однако большинство пользователей если все-таки размещают окна по экрану, то с целями практическими. Некое "потерянное" время, которое упоминает автор, слишком абстрактно. Слишком много факторов, влияющих на время существуют в обоих типах интерфейсов, и комплексная их оценка лежит далеко за пределами даннной статьи. Что касается "... вороха набросанных на экране окон и сваленных в беспорядке иконок ...", то все зависит от самого человека. Поддерживать порядок как на реальном, так и на виртуальном рабочем столе надо уметь.
Ну, есть дорогие элитные столы, в которые встроены разные полезные (и не очень) вещи, вплоть до пепельницы. Есть столы с гнездом для установки компьютера. Тумба, как правило, крепится в конкретном месте стола, а столы, которые можно конфигурировать по своему усмотрению, как правило, быстро ломаются. Есть столы, у которых регулируется даже высота столешницы, но это дорого стоит и не так уж необходимо.
А в автомобилях так вообще магнитофон, пепельница, зажигалка и прочие подобные вещи, не говоря уж об "элементах интерфейса управления" (я имею в виду руль, педали и рычаги) расположены на конкретных местах и по другому их располагают только для инвалидов.
А возвращаясь к теме компьютерного интерфейса могу сказать, что мне надо делать мою работу. Если программа, с которой я работаю, удобна, ничего другого мне и не надо, а если нет - окна не помогут.
Вот утверждение, верное на все 100%. Однако оно касается программ вообще. Конкретно оконный интерфейс здесь ни при чем.
Большинство современных операционных систем действительно имеют многозадачность и графический оконный интерфейс, либо встроенный (M$-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 ?
При этом задачи, работающие с этой консолью, даже не знают, что консоль переключили и не обязаны перерисовывать экран - все реализовано на уровне ядра операционной системы. Это обеспечивает в том числе возможность запускать на каждой консоли свою задачу, причем в т.ч. и от имени разных пользователей (это нужно, например, при настройке администратором прав доступа для работы программы, которая будет выполняться в режиме пользователя - в WindowsNT для перехода из режима пользователя в режим супервизора и обратно придется закрывать все приложения и выходить из системы с разрывом всех связей).
Да, есть такой грех за NT.
Совершенно другой метод реализован фирмой Apple на Newton Message Pad, который же изначально проектировался как портативный компьютер. Перед его создателями стояли две основные проблемы - габариты и вес - и они были удачно решены. Вес Newton'а составляет всего полкилограмма за счет перехода от аккомуляторов к четырем пальчиковым батарейкам при том, что Newton может работать сутки, а notebook - не более восьми часов; это удалось за счет отказа от жеского диска в пользу Flash-ROM и использования процессора ARM вместо i*86. Сделать Newton карманным компьютером и при этом удобным в обращении удалось за счет упора на полноэкранные приложения - перемещаемыми остались только служебные программы типа "виртуальной клавиатуры". Об этом невозможно рассказать - это надо увидеть своими глазами. Те, кто с недоверием слушал о "карманном компьютере, распознающем рукописный текст", визжат от восторга при первом же столкновении с естественным интерфейсом "бумага и ручка" (где вместо бумаги - экран, по которому пишут специальной ручкой).
Полноэкранные приложения используются на Newton'е по одной причине - его экран и так мал, его буквально некуда дальше делить.
Большинство пользователей считают, что это удобно и естественно - просто потому, что не знают о более удобных способах общения с машиной и не задумываются, почему им приходится делать множество движений для выполнения элементарных операций. Вместо того, чтобы нажать комбинацию клавиш или набрать команду, мне приходится продираться сквозь бурелом многоуровневых менюшек, каждый раз целясь мышкой в узкую полоску нужного мне пункта. Я должен помнить не только название нужного мне пункта (с такой же легкостью я бы запомнил команду), но и название пунктов по пути к нему. Неужели кто-то называет это облегчением работы?
Сложность меню определяется приложением. Если программа плохо спроектирована, это ее беда, а не беда оконного интерфейса. Тем не менее (и далее автор это признает), меню действительно быстрее, потому что на самом деле не нужно запоминать каждый пункт меню, как об этом пишет автор, достаточно их прочитать - это гораздо легче. " ... Я бы запомнил команду." - он бы запомнил, а другие ?
Выбор из пунктов меню можнет показаться легче, чем запоминание команды, но только до тех пор, пока этот выбор ограничен некоторым разумным пределом или очень хорошо структурирован. Хорошо структурированных систем я в своей жизни почти не встречал - наверно, просто очень мало вещей легко поддаются структуризации, а непомерно распухшие древовидные списки делают поиск нужного мне пункта просто мучительным. Конечно, если я сам создавал это дерево и уже долго работаю с ним, то я буду легко ориентироваться в нем; но что делать, если я должен что-то сделать на чужом компьютере? Заставить хозяина стоять рядом? Таскать всюду с собой трехкилограмовый notebook? Конечно, есть такие решения, как smart-card для Network Computer (проект фирмы Oracle) или Newton Message Pad (фирма Apple), которые всегда с хозяином и не оттягивают карман, но это пока дело будущего.
Иногда мне хочется скопировать с экрана какой-то текст, например, из заголовка окна или из списка установленных системных шрифтов.
Иногда требуется. Например, я хочу послать кому-то вопрос или совет о том, что делать в тех или иных случаях и надо описать конфигурацию, в которой та или иная программа работает (или не работает). Короче, я хочу скопировать текст, который я вижу на экране. Однако, по крайней мере программы MS Windows позволяет копировать только то, что считают нужным. Они считают, а не я!
Опять же, описанные проблемы - проблемы конкретной реализации, а не самого интерфейса. Причем здесь автор подходит к проблеме с точки зрения текстового режима работы - он хочет скопировать только текст. Однако чаще всего для описанной им ситуации требуется полное изображение, а такие вещи можно делать практически в любой системе.
Кроме того, система "наглядного копирования" имеет ряд подводных камней. Например, если я копирую (перетаскиваю мышкой) выбранный файл из одного окна File Manager в другое, это, очевидно, указание копировать (или перемещать) файл. Но если я перетаскиваю его в текст какого-нибудь текстового редактора, то что должно быть помещено в текст - имя файла или его содержимое? А если это запускаемый файл (интерпретируемый скрипт), то, может быть, надо поместить результат его работы - все, что будет выведено на стандартный вывод (stdin в языке C)? Подобные неочевидности могут привести к серьезным проблемам у пользователей с не очень большим опытом или просто не столь тщательно изучившим взаимодействие программ друг с другом как их автор. Нам непрерывно вдалбливают необходимость наглядного интерфейса, но технология drag&drop весьма далека от наглядности; для работы с информацией (в противоположность работе с материальными обьектами) эта технология скорее противоестественна.
На самом деле никто нам ничего не "вдалбливает". Эволюция интерфейсов - явление есстественное. Да, технология drag&drop имеет свои проблемы, но она имеет и преимущества.
И неужели создатели оконного интерфейса считают пользователей компьютера неграмотными тупицами? Зачем вместо текста нам предлагают картинки? Картинки хороши, когда их мало, но в куче набросанных картинок найти нужную гораздо сложнее, чем вызвать нужный обьект по имени. К тому же все равно приходится читать подписи под картинками.
Автор видимо не в курсе, что людям свойственно узнавать, а не распознавать информацию. Когда человек запоминает ассоциации иконок с действиями, работа будет выполнятся быстрее, чем каждый раз прочитывать текст. Конечно, разработка хороших иконок дело сложное, поэтому "... куча набросанных картинок ..." - пример неудачного интерфейса программы. А чтобы вызвать любой объект по имени, нужно держать в памяти имена всех объектов!
Дорожные знаки делаются в виде картинок по нескольким причинам. Прежде всего, информация с них должна быстро доходить до водителя, у него нет времени разбирать буквы. Водитель может быть иностранцем, не знающим местного языка, то есть фактически неграмотным. И наконец, никогда указатели-пиктограммы не появляются в одном месте в большом количестве. Ни одно из этих условий не выполняется для пользователя компьютера.
Дорожные знаки - это действительно хорошо продуманная система. Они хорошо различаются между собой, и видны на расстоянии.
В конце концов, "указать и нажать", а также "перетащить и бросить" можно и без окон. Point&click реализован еще в Norton Comander и Norton Utilities, а также во всех программах, использовавших мышь в качестве основного устройства ввода (типа PaintBrush) задолго до появления окнных систем. Drag&drop из одной полноэкранной задачи в другую можно делать, если во время переключения есть куда положить (например, в Newton - на поля документа) или если можно переключить задачу, не бросая то, что тащишь.
Интересно, как автор представляет себе последнее? Одно из основных правил гласит, что у человека может быть только одна точка внимания. А в данном случае он должен одновременно следить за тем, чтобы "не потерять ношу" и за тем, как переключить задачу. Переходя к устройствам ввода информации в компьютер, мы получаем какие-то акробатические этюды клавиатурой и мышью.
Ну, если рассматривать любое выпадающее или всплывающее меню как окно, то многие программы содержат в себе оконную оболочку.
Действительно, если так считать, то где же проходит граница между оконным и не-оконным интерфейсом . Видимо автор еще сам не определился с этим вопросом.
Библиотеки типа TurboVision позволяет программисту писать программы с оконным интерфейсом, причем как в текстовом экранном режиме, так и в графическом. И чем более "оконной" делается система, тем неповоротливее и прожорливее к ресурсам она получается.
Никто не спорит, что графические системы требуют больше ресурсов, чем текстовые, хотя бы потому, что вместо однго-двух байт на символ приходится оперировать десятками пикселов. За все надо платить.
Впрочем, я бы поостерегся сходу называть любую программу, которая восстанавливает содержимое экрана после себя или после другой программы, "оконной". Гораздо эффективнее, чем окна, разбиение экрана на кадры (frames). В качестве двух кадров фиксированного размера можно рассматривать Norton Comander. На кадры разбивает экран и PaintBrush. И неподвижные меню тоже представляют из себя кадры. Кадры часто используются в оконном интерфейсе, использование кадров вместо окон делает программу более удобной и эффективной.
Все таки так и непонятно, в чем же, по мнению автора, разница между "кадрами" и окнами - разве что в том, что кадры фиксированы (т.е. не требуется время на настройку их размеров и положения)? Но в том же Norton Commander'е панели можно делать больше-меньше, отключать панели и меню. Так что утверждение, что использование кадров делает программу более удобной, попросту голословно.
А мышь вообще является одним из самых неудобных устройств, которые я встречал в своей жизни. Ее основное неудобство - проскальзывание. Я двигаю мышь по столу и я уверен, что я ее подвинул - а курсор еле сдвинулся или вообще остался на месте.
Ну а с этим солгаситься довольно трудно. Большинство людей используют мышь без указанных проблем. Интересно, какое устройство автор считает удобным?
А если я повернул мышь, то направление движения курсора уже не совпадет с направлением движения руки.
Да, а если перевернуть монитор, то изображение на экране будет вверх ногами.
Гораздо удобнее работать с сенсорным экраном, но во первых, он быстро пачкается, а во вторых, работа с ним больше всего напоминает однокнопочную мышь, а мне даже три кнопки кажется маловато - я-то привык работать пятью пальцами, да еще помогать при необходимости второй рукой.
В случае обычным образом расположенного монитора прилется постоянно держать руки на весу - ну очень удобно.
Кроме того, я не чувствую, когда мышь пересекает какую-либо границу, нарисованную на экране, а вот клавиатуру я чувствую пальцами.
Можно подумать, что двигая курсор с клавиатуры, можно почувстовать границу на экране.
Известен "слепой метод" печати на клавиатуре, но никто даже не заикается о "слепой" работе мышью.
Потому что работа с мышью в действительности и является "слепой". А вы смотрите постоянно на свою мышь?
Так что ничего, более удобного и мощного, чем клавиатура и командная строка (естественно, с развитыми средствами редактирования этой самой строки) я не видел и вряд ли увижу.
Сразу видно, что это мнение программиста. Никогда не нужно забывать, что пользователи обычно делятся на две группы - профессионалов и обычных (которых большинство). И если первые могут разбираться с командной строкой и др. подобными средствами (хотя это не означает, что профессионалу не нужен удобный интерфейс для своей работы), то вторым нужны более простой интерфейс. Представте себе бухгалтера, заносящего проводки с помощью командной строки ...
Особые неудобства вызывает двойной щелчок. Как правило человек не может напрячь отдельную мышцу, напрягаются в той или иной степени все соседние. Нужно обладать поистине акробатической ловкостью, чтобы никогда не сдвигать мышь между нажатиями кнопки. Проще после выделения нажать на [Enter], но надо переносить руку с мыши на клавиатуру, а это неудобно.
Двойной щелчок действительно сложен для все пользователей. Однако похоже в последнее время все идет к тому, чтобы от него отказаться.
На мой взгляд, они скорее деградируют. Если в Windows 3.11 я мог вызвать окно Program Manager (диспетчера программ), чтобы запустить новую программу, то в Windows 95 для этого приходится либо блуждать по дереву меню кнопки "Start" (в русской версии - "Пуск"), либо закрывать все открытые окна, чтобы добраться до ShortCuts (выложенных на поверхность стола иконок). Это неудивительно, ведь интерфейс Windows 95 скопирован с Macintosh-86.
В Windows 3.11, чтобы запустить новую программу необходимо тоже или нати нужную программную группу, а в ней нужную программу, либо набрать имя файла вручную. Так что же быстрее?
Такое относительное новшество, как модальные окна, причиняет немало неудобств. Если оконная система предназначена для того, чтобы держать перед глазами одновременно несколько документов, то почему нельзя подвинуть родителя модального окна, пока не закроешь это модальное окно?
Модальные окна - одна из самых известных проблем современных интерфейсов.
При том, что версии графических операционных систем пекутся как блины, побуждая пользователей тратить на инсталляцию и настройку больше времени, чем на полезную работу, их создателям и в голову не приходит оглядеться вокруг и внести усовершенствования, которые давно есть у соседей. Пример - операции "Load" и "Save as" в MicroSoft Windows (как в 3.11, так и в 95/NT) выдают окно неизменяемого размера. при том, что в Solaris это окно можно легко растянуть и просматривать не по восемь файлов, а сколько уместится на экране. Прокрутка здесь мало помогает, ибо глазами человек двигает гораздо быстрее, чем руками.
Ну вот уже автор перешел от критики в одрес оконных интерфейсов к нападкам в адрес одной известной компании и ее маркетинговой политике. Это скорее тема отдельной статьи.
Кроме того, этот мини-File Manager не позволяет ни содать директорию, ни стереть или переименовать файл - только перейти в директорию и выбрать нужный файл. Недостатки оконного интерфейса и сочетаются с недостатками операционной системы и приложений, дополняют и усиливают их. Часто хочется вернуться к простой удобной командной строке, когда для стирания файла или форматирования дискеты не надо запускать File Manager, а можно это легко и быстро сделать прямо из редактора - даже многозадачность не понадобится.
Чрезвычайно интересно, в каком это редакторе можно стереть файл? Даже если так, то этот файл прежде необходимо найти, а окно поиска и выбора файлов есть ни что иное, как аналог того же File Manager'а.
Большинство современных пользователей работают под различными версиями MS-Windows. Для них графическая оконная система кажется единственной альтернативой кошмару командной строки DOS. На самом деле это не так. Не говоря уж об аналогичных, но более совершенных системах типа Apple Macintosh, Acorn RiscPC и X-Windows для Unix (каждая из которых в своей области намного превосходит MS-Windows),
Опять голословное утверждение.
есть и другие концепции пользовательского интерфейса. Это командная строка Unix и графический (но не оконный) интерфейс Apple Newton Message Pad.
Что касается командной строки, то даже в WindowsNT такие утилиты работы с Internet как ARP, Ping, TraceRoute, NSLookUp (не говоря уж о Telnet) реализованы в виде эмуляции текстового экрана в окне и запускаются с командной строки, хотя многим из них так и просится графический интерфейс. Интерфейс Windows95 сильно проигрывает оттого, что в них нет элементарной операции "вызвать командную строку", а то, что есть - "Start"/"Run" - долго вызывается и даже не позволяет повторить предпоследнюю команду.
????? C какой версией работает автор?
Вообще Internet, пошедший от Unix, унаследовавший многие его недостатки и достоинства, сильно привязан к текстовым форматам. Так FTP-клиенты, оформленные в виде, аналогичном FileManager, все равно посылают серверу стандартные команды, получают от него текстовые ответы и выводят этот диалог в специально отведенном месте своего окна.
Acorn OS, реализованная еще в 1982 году на восьмиразрядных машинах, позволяла легко скопировать в командную строку любую последовательность символов с экрана, причем в графическом режиме происходило распознавание символов (правда, распознавалось только полное совпадение с оригиналом). При редких обращениях к файлам, малом количестве файлов и достаточно продуманной системе команд это давало вполне приемлимый комфорт работы в командной строке.
Однако какие ограничения !
Поэтому все программы, в том числе и редакторы, имели выход в командную строку, более того - команды "загрузить файл", "записать файл", "отформатировать текст" воспринимались с той же командной строки и это было вполне удобно. Даже секретарши уверенно работали в этой среде, тем более что все часто выполняемые последовательности команд легко вызывались скриптами.
Вот здесь можно высказать сомнения.
Часто используемый в Linux командный интерпретатор bash (Born Again SHell - Возрожденный Shell) пригодный, впрочем, и для других Unix'ов, позволяет вызвать ранее введенную команду с аргументами и редактировать ее, перемещаясь стрелками. Такие же средства предоставляет командный интерпретатор Windows95 и NT, а также альтернативные командные интерпретаторы для DOS. Широко известный советскому пользователю Norton Comander и его аналоги помимо этого позволяют также скопировать в командную строку имя файла, а некоторые из аналогов - еще и путь к текущей директории. За это, кстати, их, вопреки ожиданиям MicroSoft, держат на машиных с Windows - командная строка все-таки на порядок более мощнное средство, чем мышь, тыкающая в иконки.
Держат их по дум причинам - во-первых, все просто привыкли, а во-вторых, Проводник Windows для работы с файлами вещь жутко неудобная.
...редактирование текста? Естественно, нет, хотя существовали редакторы, которые управлялись командами. Подавляющее большинство задач требуют чего-то большего, чем командная строка. Но для нормальной работы нужна интегрированная среда, к которой можно легко подключить дополнительные элементы, а не возможность таскать окошки по экрану. Некоторым приближением к этому можно считать Norton Comander. Он позволяет выполнять достаточно много часто используемых операций с файлами, а недостающие возможности легко дополняются командной строкой, пользовательскими меню и реакцией на расширения (тип) файлов. К сожалению, даже эти возможности не были доведены до логического завершения, а последние версии непомерно разбухли и вынесение многих функций в отдельные программы сделало работу просто неудобной.
NC - уникальная в своем роде программа. И все попытки развить ее во что-то еще изначально были обречены на неудачу.
Другой пример - редактор МикроМир, написанный ребятами из МГУ и распространяемый бесплатно. При размере менее 90 KB он позволяет работать с тремя независимыми буферами - поточным, строчным и прямоугольным; использовать имя файла в тексте как гиперссылку, т.е. легко перейти к этому файлу, запустить программу по его расширению и др.; сделать буквы большими, маленькими, русскими или латинскими (особенно полезно, если они набраны не в том регистре); работать в режиме таблиц, ограниченных псевдографикой; сортировать строки. Особенно радует, что можно свободно переносить текст между текстом, строкой поиска, строкой замены и командной строкой, а также то, что ранее введенные значения этих строк автоматически запоминаются и их можно легко вызвать. Разумеется, некоторые нелогичности есть и у МикроМира, тем более что новых версий не выходило с 1984-го года.
Нет, хотя запускать их можно и оттуда. Но вот выполняться они вполне могут в полноэкранном режиме, а не в оконном. Все равно даже полного экрана им мало.
А зачем? Если подумать, то окажется, что любая необходимость видеть два документа одновременно есть следствие недостаточной автоматизации либо непродуманного интерфейса. Либо нужные мне данные можно скопировать в редактируемый документ и там уже править, либо человек выполняет работу, которую мог бы выполнить компьютер. Часто приходится набивать текст, который разработчики почему-то сделали недоступным для копирования. Названия иконок, список фонтов, список задач в MS Windows - это текст, но скопировать его нельзя. А иногда компьютер принял факс и девочку-секретаршу сажают набивать текст, записанный в графический файл, вместо того, чтобы запустить распознаватель и затем редактировать полученный текст.
Почему то автор всегда упоминает документы в качестве примера окон. Существует большое количество различных программ, которые полезны как раз при одновременной работе с чем-то. А какже еще многодокументный интерфейс? Если обобщать утверждение автора, то получается, что даже Norton Commander имеет непродуманный интерфейс, потому что у него 2 окна. А описаные проблемы - опять же являются проблемами программного обеспечения, а не интерфейса.
Специалисты фирмы Xerox, когда разрабатывали оконный интерфейс ...
Да, оконный интерфейс, как и стандарт локальной сети Ethernet, был разработан в фирме Xerox, но не не был запатентован, а отдан для реализации всем желающим. Но я отвлекся. Так вот, оконный интерфейс разрабатывался как аналог рабочего стола, на котором разбросаны документы. При этом, однако, не учитывалось, что на самом деле требуется два режима: "просмотра списка документов" и "работы с конкретным документом". Человек никогда не держит перед глазами два документа - он переводит взгляд с одного на другой.
Кроме того, модель "панели управления", реализованная системой кнопок, не учитывет, что в управлении панелью огромную роль играют тактильные ощущения; для их усиления дизайнеры стараются придать кнопкам и рычагам разную форму, сделать им разную поверхность. Все это невозможно при работе с проскальзывающей мышкой и отображенными на экране кнопками. Лучше уж пользоваться комбинациями клавиш.
Тактильное ощущение в этом случает реализуется кнопкой мыши, и дополняется визуальным сигналом - нажатием кнопки. А комбинации клавиш необходимо все время держать в памяти.
Впрочем, в той же самой лаборатории PARC уже разрабатывается новый интерфейс Hyperbolic Tree, не имеющий ничего общего с окнами. Возможно, они прочитали черновой вариант этой статьи, опубликованный на WWW-сервере.
Одним из основных недостатков оконного интерфейса является его прожорливость по отношению к ресурсам. Конечно, если Вы готовы заплатить за самый мощный на сегодняшний день процессор и немеренное количество оперативной памяти, эта проблема Вас не волнует. Но вот если Вы небогаты или если у Вас этих компьютеров на предприятии не один десяток - придется задуматься. Ведь почти все современные Window Managers (диспетчеры окон) о каждом произошедшем событии оповещают задачу - хозяина окна. Потребовалось перерисовать содержимое окна или его части, нажали кнопку на клавиатуре или кнопку мыши, просто провели курсором мыши над окном - каждый раз диспетчер окон вызывает задачу. Тратится время на переключение контекста задачи, перезагружается кэш-память, происходит подкачка с диска - короче, непроизводительно расходуются ресурсы машины.
На самом деле никто и не утверждает, существующая в большинстве сегодняшних систем схема управления событиями идеальна. Однако на данном этапе альтернативы ей нет.
В этом смысле очень интересно сравнить взаимодействие программы с Window Manager'ом и взаимодействие X-терминала с хостом. Если компьютер с принтером можно рассматривать как мини-сеть, то почему бы взаимодействие программ не рассматривать как клиент-серверное? Так вот, X-терминал посылает сообщения хосту о каждом событии - тычке мышкой, нажатии кнопки, необходимости перерисовать окно. А вот HTML/Java-терминал тривиальные случаи (перерисовку, прокрутку, ввод символов в поля ввода) обрабатываются встроенной программой (browser'ом), для не очень тривиальных в составе страницы есть программки на Java и JavaScript, а самые неривиальные, требующие новых данных, передаются на WWW-сервер. Примерно такую же модель давно надо было реализовать и в оконных системах. Я не уверен, что при выполнении задач, ядра OS и драйверов на одном процессоре нужен промежуточный слой программ обработки "не очень тривиальных случаев", хотя для ассиметрично-мультипроцессорной архитектуры (каковой является сеть) это очень удачное решение. Примерно такая схема, насколько я знаю, была реализована в RiscOS - задача может передать окно модулю, который берется за обслуживание сообщений к этому окну. При этом окно должно быть описано в определенных терминах - здесь картинка, здесь текст, а здесь кнопка - и задача, создавшая окно, будет обрабатывать только то, что не удается описать в рамках понимаемых этим модулем терминов; впрочем, туда были включены все наиболее часто используемые элементы. К сожалению, этот способ сделать оконные программы более компактными так и не перекочевал в другие операционные системы.
Обьектно-ориентированное программирование - один из способов скрыть от программиста детали реализации. Это хорошо только если надо быстро написать программу, которая потом будет не слишком часто выполняться. Или если надо написать переносимую между разными платформами программу (в надежде, что на каждой платформе уже есть нужные библиотеки). Избежать обработки всех подряд событий можно только поручив Window Manager'у обрабатывать тривиальные элементы окна.
Да, действительно, большинство операционных систем сейчас не являются в действительности объектно-ориентированными. Это сложилось во-первых исторически, а во-вторых - объектный механизм тоже требует дополнительных ресурсов.
А пока Window Manager не умеет сам обрабатывать такие события, программа на обьектно-ориентированном языке все равно будет обрабатывать все события; даже если программист проигнорировал какой-либо тип события, компилятор сам добавит "стандартный обработчик", бессмысленно пожирающий ресурсы машины.
Ну, ресурсы машины как бы не очень жалко - машина железная, пусть работает. Жалко пользователя, который тратит кучу времени, пытаясь красиво расположить окошки на экране, вместо того, чтобы работать;
Не стоит жалеть такого пользователя.
а как только добавился новый элемент, приходится повторять всю процедуру снова. Это - один из примеров того, что гибкость системы отнюдь не всегда способствует удобству работы.
А для многих задач коллективной работы с каким-либо набором данных зачастую достаточно мощного компьютера, к которому подключены дешевые текстовые терминалы. Существенное преимущество такого подхода - резкое снижение стоимости всей системы при большом рабочих мест и снижение загруженности сети. (Еще меньше загружают сеть HTML- и Java-терминалы, но они сложнее и поэтому дороже.) Вдобавок SQL-клиент, выполняющийся на одной машине с SQL-сервером и отображающий результаты своей работы в виде терминальных управляющих Escape-последовательностей либо в виде HTML, гораздо быстрее осуществляет транзакции, чем SQL-клиент, выполняющийся где-то в сети. У текстового терминала, кстати, гораздо меньше уровень электромагнитного излучения и выше качество изображения, но об этом мало кто задумывается.
Где конкретные данные?
Ну, для системного администратора, на мой взгляд, "наглядное графическое представление данных" просто опасно - освоивший технологии "укажи и нажми", а также "перетащи и брось" берется за управление системой, не освоив основ ее функционирования.
Почему же опасно - любой человек обучается гораздо быстрее в дружественной среде, которая позволяет себя исследовать, и может всегда вернуться к предыдущему состоянию в случае сбоя.
Хуже того - очень многие начинают путать интерфейс представления данных с самими данными. Это не страшно до тех пор, пока система функционирует в рамках, описываемых интерфейсом, т.е. в пределах того, что предусмотрено ее создателями. Но, как известно, катастрофы не требуют планирования, а любая нештатная ситуация потому и нештатная, что не предусмотрена создателями системы (иначе система сама бы справилась). При этом я сошлюсь на PC Week 12(86) от 1..7 впреля 1997, статья Леонида Миронова "Нужен ли ГИП(GUI) для серверной ОС?".
Если Вы настраиваете IP-маршрутизатор, никакой графический интерфейс не позволит Вам обойтись без знания таких вещей как "номер сети", "маска", "шлюз"; настройка DNS (сервера доменных имен) требует знать, что обозначают записи MX, NS, A, PTR, HS-INFO; а борьба с сообщением "No access" ("недоступно") требует разбираться в правах доступа.
Что же это система, в которой пользователю приходится "бороться" с сообщениями?
И "интуитивно понятный интерфейс", даже с "контекстной подсказкой" мало поможет, если нет фундаментальных знаний.
Установка атрибутов доступа каким-нибудь Security Manager (менеджером безопасности) ничем не поможет, если в системе есть хоть один способ доступа в обход этих атрибутов, в то время как все программы будут показывать, что система полностью закрыта от нежелательных лиц. Как можно определить, что в системе настежь открыта "задняя дверь"? Только детально разбираясь в "потрохах" системы, не полагаясь на сообщения привычных утилит, тем более что однажды проникший в систему злоумышленник вполне мог заменить эти утилиты на свои, которые никогда уже не скажут правды законному администратору.
А теперь представьте себе, что управление ядерным реактором доверено оператору, который полагается на "наглядный" графический интерфейс. Пока все идет как надо, оператор легким движением мыши управляет работой реактора, основываясь на наглядно представленных параметрах функционирования. Но вдруг он промахнулся и нажал не ту кнопку (а для нажания кнопки, изображенной на экране, не нужно откидывать предохранительный колпачок, даже если это кнопка самоликвидации путем атомного взрыва). Или реактор самопроизвольно перешел в режим, не предусмотренный создателями программы. Или сломался какой-нибудь из управляющих элементов. Если оператор изучал реальное устройство реактора, а еще лучше - принимал участие в монтаже, он сможет, манипулируя оставшимися в его распоряжении средствами управления, удержать реактор от взрыва. А если он привык к своему интерфейсу и не знает ничего о реальном реакторе, которым управляет?
А где вы видели программу, в которой достаточно серъезное действие выполняется случайным нажатием кнопки? Программы же для реакторов должны разрабатываться самым серъезным образом.
Да, но им тоже не помешает знать детали функционирования системы. Когда в 1987..1992 годах я работал на компьютерах фирмы Acorn, модель B+, я заметил прекрасной свойство операционной системы: системный вызов OSByte соответствовал команде *FX, т.е. команда
*FX аргумент1 аргумент2 аргумент3
с числовыми аргументами соответствовала ассемблерному коду
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
уже нет такого однозначного соответствия.
DOS рассчитана на пользователя, который никогда не слышал слова Assembler. Но к чему это вообще? Где же проблемы оконных интерфейсов?
Однако пользователь легко может написать script или, как его называют в DOS, batch-файл (по русски - пакет команд), который будет содержать команды, обычно подаваемые с клавиатуры. Пользователь может облегчить себе жизнь, но стать программистом ему будет гораздо труднее.
А зачем? Неужели все пользователи должны стать программистами?
А вот в системах с "менюшным" интерфейсом создать пакетные задания гораздо сложнее - между пользователем и программистом пролегает почти непреодолимая пропасть. Именно поэтому удобные пользовательские интерфейсы создаются людьми, которые прошли огонь, воду и медные трубы примитивной командной строки без средства редактирования, да еще в отсутствии удобных утилит - но чем удобнее созданный ими интерфейс, тем быстрее система перестает развиваться, впадает в стагнацию. Избежать застоя, насколько мне известно, удалось только Acorn и Unix. Acorn изначально разрабатывал комплексное решение, включающее сам компьютер и программное обеспечение (от ядра операционной системы до текстовых редакторов), зашитое в ПЗУ. Основную прибыль приносит продажа "железа", поэтому фирма оказалась заинтересована в расширении круга програмирующих для этой платформы. ПО (как фирменное, так и независимых производителей) строится из независимых модулей, связанных протоколами вызовов. Наиболее популярные (часто используемые) модули включаются в ПЗУ следующих версий.
Unix - уникальный феномен многих операционных систем для разных аппаратных платформ, обьединенных общими стандартами. Несмотря на наличие нескольких семейств, таких как System V и BSD, а также множества диалектов типа QNX, Unix'ы сохраняют совместимость на уровне исходных текстов программ (откомпилированные программы не переносятся не только на другой процессор, но и на другой Unix, работающий на том же процессоре). Переносимость программ удивительна даже по сравнению с совместимостью разных версий одной операционной системы одной фирмы для конкретной платформы. Жизнеспособность Unix долгое время поддерживалась доступностью исходных текстов ядра и утилит; в последнее время исходные тексты коммерческих Unix'ов недоступны, но появились бесплатный FreeBSD (в противоположность платному BSDi) и "народный Unix" Linux. Жизнеспособность Unix поддерживается прежде всего конкуренцией среди разных групп программистов, каждая из которых стремится сделать свой Unix лучше других, а лучшие решения быстро перекочевывают во все другие реализации.
Что касается Unix'а. Фраза "обьединенных общими стандартами" довольно интересна. На самом деле она обозначает существование множества стандартов на одно и то же. Разве нормальному пользователю есть дело до исходных кодов программы? В действительности, удивительно, как клон Unix до сих пор жив.
Я так не думаю. В соответствии с законом возрастания энтропии, мир с течением времени становится все хуже. :-) Если мы подождем еще немного, то увидим возникновение нового, еще более неудобного интерфейса. Возможно, это будет голосовой интерфейс, когда заика или просто простуженный человек по ошибке вместо того, чтобы послать электронное письмо, сотрет все свою работу за последние полгода. Ведь компьютер хорош тем, что делает ошибки во много раз быстрее человека. :-) Так что лет через десять я напишу статью, в которой буду ругать этот новый мерзкий, неудобный, неестественный интерфейс и с тоской вспоминать, как старые добрые окна легко управлялись мышкой. :-)
Оказывается автор еще и специалист по энтропии? И фантазии ему, так же как и способности искажать факты, ему не занимать. Эволюция интерфейсов идет своим чередом, и идет уверенно. Каждое новое поколение интерфейсов есстественно имеет свои проблемы, но зато оно решает проблемы предыдущих. Давайте все-таки надеятся, что мы с вами еще застанем действительно удобный интерфейс.
В заключении можно сказать, что автора в действительности все время клонит в сторону оконных интерфейсов, чему он всеми силами сопротивляется, приводя голословные обвинения и приписывая оконному интерфейсу несвойственные ему проблемы.