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

Дмитрий Карпов

Продолжение.

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

А разве Norton Comander и ему подобные программы не являются оконными?
Ну, если рассматривать любое выпадающее или всплывающее меню как окно, то многие программы содержат в себе оконную оболочку. Библиотеки типа TurboVision позволяют программисту писать программы с оконным интерфейсом, причем как в текстовом экранном режиме, так и в графическом. И легко заметить, что чем более "оконной" делается система, тем неповоротливее и прожорливее к ресурсам она получается, а увеличение количества "наворотов" делает систему неудобной для пользования.
Впрочем, я бы поостерегся с ходу называть любую программу, которая восстанавливает содержимое экрана после себя или после другой программы, "оконной". Гораздо эффективнее, чем окна, разбиение экрана на кадры (frames). В качестве двух кадров фиксированного размера можно рассматривать Norton Comander. На кадры разбивает экран и PaintBrush (в отличие от него, PictureManager фирмы Cognitive Technologies держит панели инструментов в виде отдельных окон). И неподвижные меню больше похожи на кадры, чем на окна. Кадры часто используются в оконном интерфейсе, использование кадров вместо окон делает программу более удобной и эффективной.
Основная разница между кадрами и окнами в том, что кадры всегда плотно прилегают друг к другу - не наезжают друг на друга и не оставляют свободного места; если пользователь уменьшает один кадр, освободившееся пространство тут же забирает другой кадр. Не все кадры допускают изменение размера - например, элементы оконного интерфейса, имеющиеся в каждом окне, тоже можно рассматривать как кадры, отнимающие пространство у основного кадра, в котором происходит работа.
Я не утверждаю, что оконный и кадровый интерфейсы - два разных, несовместимых подхода: во многих программах можно найти сочетание обеих технологий. Я также не утверждаю, что кадровый интерфейс удобнее оконного: все дело в умеренном и продуманном употреблении. Просто оконный интерфейс, воспеваемый как необходимый для удобной работы, уже дошел до маразма, а кадровый еще относительно слабо применяется, хотя в "1С Бухгалтерии 6.0" я видел пример неудобного обращения с кадровым делением экрана.
Вообще система разбиения экранного пространства на кадры, как мне кажется, сильно отстает в своем развитии от оконной системы. Элементы оконного интерфейса, такие как заголовки окон, выпадающие меню, полосы прокрутки и диалоговые окна, реализованы в виде стандартных методов (часто крайне неудачно), а разбиение на фреймы каждый программист реализует кто во что горазд. Вот краткий список претензий:
Нигде не реализована смена схемы разбития:
"горизонтальное"
-|-|-|-|-
-|-|-|-|-
-|-|-|-|-

"вертикальное"
-|-
-|-
-|-
-|- -|-
-|-
-|-
-|- -|-
-|-
-|-
-|-
"смешанные"
-|-|- -|-|-
-|-|-
-|-|-
-|-|-
-|-
-|-
-|-
-|- -|-|-|-
-|-|- -|-
-|-
-|-
-|-|-

Это легко объяснимо: трудно наглядно указать, как именно мы хотим расположить фреймы. Операция, элементарно выполняющаяся редактированием frameset'а, становится невообразимо тяжелой при попытке реализовать ее перетаскиванием.
Нигде не реализован механизм, автоматически увеличивающий активный фрейм (тот, в котором работает пользователь). Увеличение должно происходить при тычке мышкой во фрейм или даже при наведении курсора на фрейм и задержке его там на некоторое заданное время.
При сдвиге границы между фреймами используются весьма несовершенные механизмы принятия решения о том, как должны меняться размеры остальных фреймов; по крайней мере я ни разу не видел, чтобы при этом учитывалось самое актуальное, а именно - содержимое фрейма.
Чрезмерно увлекающиеся фреймами web-мастера часто делают фреймы с неподвижными границами - на экране другого разрешения и/или с другим размером шрифта часть содержимого может уйти за границу фрейма, и ее оттуда никакими силами не достанешь! :-(
Мышь вообще является одним из самых неудобных устройств, которые я встречал в своей жизни. Ее основное неудобство - проскальзывание. Я двигаю мышь по столу и я уверен, что я ее подвинул - а курсор еле сдвинулся или вообще остался на месте. А если я повернул мышь, то направление движения курсора уже не совпадет с направлением движения руки. Есть оптические мыши - они не проскальзывают, но боятся не только перекоса мыши, но и перекоса коврика, которого избежать гораздо сложнее. Гораздо удобнее работать с сенсорным экраном, но, во-первых, он быстро пачкается, а во-вторых, работа с ним больше всего напоминает однокнопочную мышь, а мне даже три кнопки кажется маловато - я-то привык работать пятью пальцами, да еще помогать при необходимости второй рукой. И, скорее всего, придется пользоваться специальной ручкой - палец слишком толст по сравнению с разрешающей способностью зрения и экрана.

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

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

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

Но ведь оконные системы совершенствуются.
На мой взгляд, они скорее деградируют. Если в Windows'3.11 я мог вызвать окно ProgramManager (диспетчера программ), чтобы запустить новую программу, то в Windows'95 для этого приходится либо блуждать по дереву меню кнопки "Start" (в русской версии - "Пуск"), либо закрывать все открытые окна, чтобы добраться до ShortCuts (выложенных на поверхность стола иконок). Это неудивительно, ведь интерфейс Windows'95 скопирован с Macintosh'86.
В Windows'3.11 ProgramManager позволяет открыть все свои окна и расположить их так, чтобы они не перекрывались - как бы разбить пространство на кадры. При этом я вижу все иконки программ, но они разбиты на группы, причем переход между иконками осуществляется стрелками, а между группами - 'Ctrl+Tab'; "мозаика", адаптированная к числу иконок в каждом окне, фактически эквивалентна разбиению главного окна на фреймы. ProgramManager в 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. Поверх активного окна могут удержаться только те, кто специально этого хочет - из таких программ я могу вспомнить только "Сlock" ("Часы"). В то же время в 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 Comander и его аналоги помимо этого позволяют также скопировать в командную строку имя файла, а некоторые из аналогов - еще и путь к текущей директории. За это, кстати, их, вопреки ожиданиям MicroSoft, держат на машинах с Windows - командная строка все-таки на порядок более мощное средство, чем мышь, тыкающая в иконки.
Командные интерпретаторы в Unix'ообразных системах также, как правило, умеют дозаполнять частично введенные строки (это с них скопированы аналогичные функции в 4dos и cmd.exe Windows'NT). zsh - соптимизированный для интерактивной работы вариант bash - позволяет гибко настраивать подобное заполнение. Ему можно объяснить, например, что аргументы команды mkdir или cd надо заполнять только именами директорий, а не директорий и файлов, как обычно, а аргумент команды mail, если ему не предшествует никакой ключ, - именем пользователя.
Интересная командная строка у маршрутизатора Cisco. Многие команды имеют тьму аргументов; запомнить их все очень сложно, поэтому используется контекстная подсказка: набрав часть аргументов, можно нажать "?" и получить список возможных продолжений (аргументов) с пояснениями, что чего значит, а в командной строке снова будет набранное перед нажатием вопроса. (Повтор предыдущих команд, как в bash, разумеется, тоже есть.)

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

Продолжение следует.

Дмитрий Карпов