Архивы: по дате | по разделам | по авторам

Лики интерфейсов

АрхивПрограммазм (архив)
автор : Алексей Федорчук   24.02.2001

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

Должен заметить, что непосредственным поводом для этой заметки послужили материалы Максима Отставнова о рабочих десктопах (Компьютерра, 2000, #45-46 (374-375)). Хотя основу ее составили многолетние размышления о рабочих средах - к этой тематике я давно испытываю слабость.

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

Традиционно в ONIX-системах (да и всех прочих - тоже) выделяется два класса сред, называемых обычно рабочими. К первому классу относятся вариации на тему командной строки. Именуется этот класс текстовым, или интерфейсом командной строки, представители его - всякого рода оболочки (shell), командные интерпретаторы (типа товарища COMMAND.COM'а) и так далее.

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

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

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

Применяемая в отношении этих классов терминология далека от адекватной. Действительно, в первом случае класс среды определяется на основании ее интерфейса (интерфейс командной строки, Command Line Interface или сокращенно CLI), во втором же - по используемому средой режиму (конкретно, графическому, откуда и происходит Graphic User Interface, сокращенно GUI).

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

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

Начнем с CLI. Казалось бы, наиболее полная его реализация - текстовая консоль Unix и его открытых аналогов. Однако вспомним о эмуляторах терминалов - xterm, rxvt и прочих, имя которым - если и не легион, то на когорту наберется точно.

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

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

Несколько слов о том, почему я применяю термин "среда" не только к интегрированным системам типа Windows или KDE, но и к системам, основанным на интерфейсе командной строки. Мне представляется, что он хорошо отражает смысл английского слова "Shell", используемого для разнообразных командных интерфейсов. Ведь "shell", кроме всего прочего, и раковина, в которой обитает моллюск. Для которого это - пространство его жизнедеятельности, то есть - среда обитания.

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

Термина "графическая среда", как, впрочем, и "графический десктоп" - также не "совершенно верное определение". Ведь основной принцип работы в таких средах - манипулирование интерфейсными элементами (и вообще объектами) с помощью указательного устройства (обычно - мыши). Зачатки чего имелись уже в незабвенном детище командира Нортона - программе, как известно, чисто текстовой. А в весьма развитом виде эти методы реализовались, например, в Borland'овской QuattroPro для DOS 4-й версии.

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

Затрудняюсь сказать точнее, но то, что именуется графическими средами, скорее следовало бы называть объектными, манипуляционными или как-то в этом роде. Хотя все эти термины неудачны - первый из-за ассоциации с ООП в понимании Грэди Буча (к коему в общем случае иметь отношения вовсе не обязан), второй - просто из-за трудновыговариваемости.

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

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

Для примера: вы пытались когда-либо объяснять по телефону, как выполнить с помощью компьютера некое действие? Если да - знаете, что при использовании DOS это вполне проходило, в Windows же - получалось скверно...

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

Причем, опять-таки, термин "среда" вполне логично применить не только к интегрированным визуальным системам типа KDE, GNOME или того же Windows. Но и просто к оконным менеджерам, именуемым также к диспетчерами окон. Поскольку разница между ними - только количественная. И посредством такого оконного менеджера, как FVWM, скажем, можно собственноручно собрать интегрированную среду со всеми ее атрибутами.

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

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

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

И почему пользователи DOS (опять же, знаю по собственному опыту) при первой возможности отказывались от COMMAND.COM и его среды в пользу чего угодно - ограниченного (хотя и удобного) Norton'а, удручающего GEM'а, ни с чем не совместимого Geoworks'а и даже убогого, аки сирота казанская, Windows первых реализаций?

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

Однако в дальнейшую дискуссию вдаваться не желаю. Тем более, что Unix-системы демонстрируют примеры эффективного взаимодействия между командными и визуальными средами, приемами работы прямыми директивами и манипулированием объектами (за что его, в частности, и любят). Выступающими здесь в виде пресловутого диалектического единства, о котором так много врали большевики, учившие диалектику не по Гегелю (подозреваю, даже и не по Бабелю - скорее по братьям Маузер).

Хотите пример? Извольте: файловый менеджер, он же браузер, konqueror  [1] из интегрированной среды KDE. Объединяющий разнообразные средства визуализации файловой системы, манипулирования объектами, перетаскивания мышью и прочих атрибутов GUI с полнофункциональной командной средой эмулятора терминала. Что хотелось бы проиллюстрировать рисунком.


Файловый менеджер konqueror объединяет удобство визуальной среды с эффективностью и быстродействием среды командной.

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


[1] - "Родной" сайт konqueror - www.konqueror.org, однако на момент публикации статьи ни он, ни сайты www.kde.com и apps.kde.com доступны не были. - прим.ред.
[обратно к тексту]

Обсуждение статьи - в форуме "Обсудим "СофтТерру"

© ООО "Компьютерра-Онлайн", 1997-2024
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.