Визуализация в ОС - История
Термин “визуализация данных” означает, что у нас есть некоторые данные, например таблица с числами. И эти данные нужно “донести” к конечному пользователю, и не просто “донести”, а представить в удобной, понятной, и, самое главное, в визуальной форме. Данные в этом понимании есть просто некоторые абстрактные типы данных, которые нужно представить. С этой точки зрения, и элементы пользовательского интерфейса, и результат работы электронной таблицы, и результат моделирования в CAD/CAM программах, и даже дерево каталогов файловой системы - это все данные, которые нужно отобразить. Следует заметить, что разницы между этими, на первый взгляд разнородными данными, для системы отображения нет. Правда, когда речь идет о пользовательском интерфейсе, то тут появляются некоторые специфические условия, например интерактивнось, которые должны выполняться и которых нет, например, в системе отображения CAD-программы. Так что мы сначала рассмотрим технологии интерфейсов, а потом поговорим о более общем случае, когда нужно отображать данные любой природы.
Условно интерфейсы можно разделить на 3 группы:
* Текстовые (текст ориентированные) интерфейсы.
* Смешанные (псевдографические) интерфейсы.
* Графические интерфейсы.
Текстовые (текст ориентированные) интерфейсы.
Как уже канонический пример можно привести интерфейс командной строки DOS или shell-интерпретатор UNIX. Пользователь взаимодействует с вычислительной системой с помощью клавиатуры, набирая специальные команды, для задания различных опций служат параметры. Система как ответ на действия пользователя тоже выдает или сообщения, или результат выполнения введенной команды, опять же в текстовом виде. Курсор может иметь вид мигающего прямоугольника или черточки, обозначающей место ввода. В таком режиме можно одновременно взаимодействовать лишь с одной программой, хотя потенциально могут выполняться несколько различных программ. Управлять взаимодействием этих программ можно лишь только опять с командной строки, причем проверить результат можно только по окончанию работы.
Рис. 1 Текстовый интерфейс режима MS DOS.
Главный недостаток подобных систем - для эффективного использования их пользователю необходимо знать синтаксис всех команд, плюс знать какие нужно использовать ключи или опции для каждой из них. Кроме того, текстовая природа выводимых данных делает трудной, а подчас и совершенно невозможной работу с определенным классом приложений, в первую очередь графических, или тех, где используются разнородные данные, например Web-броузеры (текстовый Lynx не пример, так как без поддержки фреймов, графики, таблиц и других элементов HTML 4.0 не идет ни в какое сравнение с Mozill-ой).
Единственной нишей, где подобный интерфейс сохранился и имеет более или менее прочные позиции, является удаленный доступ для администрирования или настройки сервера, когда требуется лишь shell-доступ, и в наличии часто есть только канал с ограниченной пропускной способностью. Так что пока жив telnet, различные эмуляторы терминалов TTY, VT100, ANSI будут продолжать работать в современных ОС.
Но, с другой стороны, в мире UNIX и его клонов командный интерфейс тоже не сдает позиций. Его преимущество - возможность программирования всей системы на встроенном в систему языке, С++ и Shell - вот поразительная мощь UNIX-систем, ведь стирается грань между программистом и пользователем. Организовать, например, связь между двумя программами, пара пустяков - одна строчка, в которой вызываются обе программы, связанные оператором перенаправления вывода. В Windows-системах за достижение подобной гибкости приходиться расплачиваться огромными надстройками COM/ActiveX/Corba, которые при этом еще и ненадежны. Правда, необходимо разграничить применение этих систем - гибкость и сложность командного интерфейса предназначена в первую очередь для профессионала, а ОС семейства Windows упорно позиционируются как “ОС для домохозяек”.
Преимущество командной строки как средства взаимодействия с вычислительной системой еще и в том, что она требует определенной культуры поведения и четкости мысли пользователя. Пример: в Windows после нажатия Alt-Ctr-Del ошибка в позиционировании курсора на 20-30 точек влечет за собой или завершение выполнения одной программы, или завершения работы всей системы. Попробуйте ошибиться так в режиме командной строки - для выхода там как минимум нужно набрать совсем другую последовательность, “logout”, “exit” или еще что-то столь же приметное - с другой командой спутать уж никак не получиться. Или, например, чтобы сформатировать дискету, нужно продираться сквозь различные “дружелюбные” окна и задавать кучу опций вместо того, что бы просто набрать всем понятную команду format a:\ .Так что командная строка останется как пользовательский интерфейс там, где работают именно профессионалы, и где не требуется сомнительных удобств и красот в ущерб функциональности и гибкости.
Смешанные (псевдографические) интерфейсы.
В первую очередь следует различать понятия “оконный” и “графический” интерфейсы. Первый базируется на принципе разделения реального окна монитора (или виртуального десктопа намного большего размера, чем физический дисплей) на прямоугольные области, внутри каждой из которых определенная программа направляет свой вывод и откуда получает команды. Никто и нечто не ставит никаких ограничений на природу этих окон - это могут быть как независимые текстовые терминалы, так и окна, куда выводиться графика (как результат работы, так и элементы интерфейса). А термин “графический” означает, что все выводиться в графическом режиме, так что может быть как оконный графический интерфейс, когда каждое окно отображает графический интерфейс, так и полноэкранный режим, когда выполняется только одна программа, которая осуществляет вывод в графическом режиме. То есть, оконный не обязательно графический, а графический не всегда оконный.
Псевдографическими я обозначаю интерфейсы, где уже присутствуют графические интерфейсные элементы, например кнопки, индикаторы прогресса выполнения, меню, но все это реализуется с помощью псевдографики набора ANSI. Как пример, можно привести всем известную оболочку FAR.
Рис. 2 Псевдографический интерфейс оболочки FAR.
Для пользования этой системой уже не нужно наизусть помнить многочисленные команды и опции, сообщения имеют более удобный и привычный вид, кнопки, как видите, достаточно интересно сделаны с использованием знаков []. Но интерфейс все равно остается текст ориентированным, а значит трудности с отображением различных данных остаются - о типе файла можно узнать только по расширению, а не как в Windows - еще и по иконке. Для выполнения простых команд типа копирования задействование мыши минимальное или вовсе отсутствует, возможности настройки внешнего вида панелей тоже очень маленькие. Соединенные с мощью командных языков shell в мире UNIX подобный подход обеспечивает практически такую же гибкость, что и текстовый, но тут уже встает вопрос о необходимости - ведь имея развитый язык, пользователь сам может настроить интерфейс для себя, без дополнительных утилит “на все случаи”.
Так что псевдографический интерфейс является как бы промежутком между чисто командным интерфейсом и графическим. Он в большинстве случаев обладает всеми преимуществами первого (использование мощных языков, расширяемость), и устраняет некоторые недостатки (позволяет легче управлять системой, нагляднее представить файловую систему, например). Но большинство недостатков практически те же - бедность вариантов представления данных, невыразительность интерфейса, нарастающая сложность при попытке перенести команду с множеством опций в режим, когда в окне нужно просто выбрать нужные пункты - на
рис. 2 видно, что в окне команды “Копировать” есть пункт “Дерево”, выбор которого приведет к открытию еще одного окна, с деревом каталогов - так что уже есть где запутаться, тем более что переключаться произвольным образом между окнами нельзя.
Следует еще упомянуть о других реализациях текстовых оконных интерфейсов. Например, замечательная операционная система Oberon имеет текстовый оконный интерфейс, основанный на концепции не перекрывающихся окон. Неудобства от подобных “штучек” нет - все, что ты запустил, прекрасно видно на экране, а если размеры дисплея не позволяют удобно разместить несколько окон большого размера, значит нужно так рационально спланировать работу, что бы было открыто ровно столько окон, сколько необходимо. Неперекрываемость окон автоматически снимает с пользователя заботу о поисках нужного окна в “куче”, сваленной на виртуальный рабочий стол, а также методическое расставляние нужных окон, которое повторяется каждый раз после активации нужного (если оно лежит где-то в глубине).
Рис. 3 Экран компьютера под управлением ОС Oberon. Оконная текстовая система с не перекрывающимися окнами.
К смешанным текстово-графическим интерфейсам еще можно отнести и ОС Plan 9. Наряду с текстовыми окнами, там используется и графика, но только в меру необходимости. Излишних красот там нет, но удобство и функциональность, как с точки зрения программиста, так и пользователя - выше всяких похвал.
Рис. 4. Экран ОС Plan 9. Концептуально родственник Oberon-на, но смешанный - текстово-графический.
Графические интерфейсы.
К этому типу я отношу все оконные чисто графические системы - Windows, оболочки для UNIX - KDE, GNOM, CDE, X-Window, Photon из ОС QNX, Aqua из MacOS X. Графическими они називаються потому, что все элементы пользовательского интерфейса, как и сами данные в окнах, отображаются в графическом режиме, с помощью 256, 16-битной или 32-битной глубины цветового буфера. Это позволяет сформировать привлекательные с точки зрения пользователя окна, кнопки, пиктограммы, ползунки, индикаторы. В таком режиме “объемность” интерфейсных элементов достигается с помощью искусственных приемов - например, за несколько пикселей до края рамки окна дают полоску белого толщиной в один пиксель - появляется иллюзия того, что рамка как бы выпукла.
Общим для всех этих систем есть понятие окна. Окно - прямоугольная область экрана, куда программа выводит свои данные и откуда получает команды. Есть два различных подхода.
Первый - десктоп имеет размеры монитора - физического устройства отображения. Как пример - Windows, MacOS. Окно, которое имеет максимальные размеры, занимает весь экран. Давайте сначала рассмотрим два скриншота системы Windows.
Рис 5. Оконная система ОС Microsoft Windows 98. Окно занимает максимальную область десктопа.
Обратите внимание - внизу, на панели задач, в данный момент открыто множество других окон. Но сейчас все они неактивны, и что особенно, навигация между ними очень затруднена - панель задач имеет маленькие размеры, а окон много, поэтому их заголовки отображаются сокращенно, и, как видно, по ним абсолютно нельзя сказать, что открыто в том или ином окне. Вот и главный недостаток подобной системы - при превышении некого лимита открытых окон практически невозможно при свернутом состоянии определить, что же там отображается. Значит, для поиска нужного окна сначала требуется по очереди открывать все окна и просматривать - как минимум, эта процедура занимает много времени. Следующий вариант - держать открытыми сразу много окон ( в смысле - отображать все окна, просто с разной степенью “раскрытия” и перекрытия между соседними).
Рис. 6. ОС Windows 98. Открыто и отображается сразу несколько окон.
Как видно, активным в каждый момент может быть только одно окно, и разница между активным и неактивным очень маленькая - всего лишь в цвете заголовка окна. Для достижения того, что бы отображались все окна пришлось так “урезать” их размеры, что работа с такими окнами очень утруднена, навигация между ними осталась практически такой же сложной.
Вообще, эти интерфейсы представляют собой метафору “рабочего стола” - экран - поверхность стола, бумаги и документы - окна. Значит, все проблемы “традиционных столов” остаются - посмотрите на свой стол, он всегда завален кучей различных бумаг, и отыскать в этом всем нужный документ недельной давности ох как нелегко. То же твориться и на столе виртуальном (Рис 6.). Пока на столе (экране) один документ (рис. 5.) то можно спокойно работать, но когда их количество переваливает за десяток… Перекрытие как метод отображения сразу нескольких документов не только не решает проблему, а наоборот, еще и усугубляет ее, так как нужно следить за тем, какой из документов/окон сейчас активен, а поиск в мешанине окон тоже не очень приятен. Вот это и есть еще один существенный недостаток оконных систем с перекрытием окон - трудность с расположением и навигацией между отдельными окнами.
Второй подход - система формирует виртуальный десктоп гораздо большего размера, чем дисплей. Окна могут размещаться на всей площади этого десктопа, а на экране отображается лишь те окна или их части, которые попадают в область отображения реального экрана. Такой подход обязывает постоянно и независимо от других окон держать в видимой области окно специальной программы - оконного менеджера, который показывает в масштабе расположение всех окон на виртуальном десктопе и ту область, которая отображается в данный момент. Навигация в таких системах похожа на стратегические игры - шарите по десктопу в поисках нужного окна с документом. Но обычно это намного легче, чем рыться в куче кое-как сваленных окон (рис. 6)
Рис. 7. Окно ОС FreeBSD с графической оболочкой Motif. В верхнем правом углу представлено окно оконного менеджера, в котором отбражается структура всех окон на виртуальном десктопе и позиция текущего окна (того, которое отображается на реальном дисплее).
Следует упомянуть еще об одном “подводном камне” всех графических оконных систем. При их использовании возникает так званый эффект “когнитивной перегрузки” - когда на экран выводиться столько различной информации, за которой нужно следить, да еще и в разных частях дисплея, что пользователь просто теряется, “глаза разбегаются”. Посудите сами: нужно следить за курсором, держать во внимании панель инструментов, где и какая кнопка нажата, следить за индикатором раскладки клавиатуры, за самой клавиатурой (Caps Lock), одновременно нужно знать, какое окно активно, и что делает система в данный момент. Не многовато ли? Кроме того, что бы выполнить любую элементарную операцию, нужно найти курсором (значит, перевести внимание на него, но другие “очаги внимания”, описанные выше, тоже нужно держать в поле зрения) пункт меню или нужную кнопку, попасть на нее, удостовериться, что ты держишь курсор именно над той кнопкой, что нужно, нажать ее, если это ползунок перемещения, то не останавливая нажатия, одновременно следить за тем, как исполняется наша команда. А как часто вы не попадали по нужной кнопке или пункте меню? И сколько раз приложение вдруг совершало не ту команду или вообще закрывалось?
Стандартизация элементов пользовательского интерфейса Windows по идее ее создателей должна было навести лад среди приложений и избавить пользователей от изучения нового интерфейса при переходе на новую программу. В какой то мере она сделала свое дело, и по крайней мере закрыть/ минимизировать/ раскрыть окно сможет каждый и с любой программой. Но что делать с другими кнопками? То, что все они имеют стандартный цвет и размер, примерно одинаковое размещение и функциональное предназначение приводит к тому, что пользователи очень часто даже не смотрят на кнопку, прежде чем ее нажать, срабатывает подсознательный рефлекс “В Word-е она означает то-то и то-то, значит и тут тоже самое”. А как раз в этой программе разработчики для этой кнопки определили совсем другую функциональность, зачастую совсем противоположную той, о которой думает пользователь. Так что такое “решение на все случаи жизни” имеет и отрицательные стороны - никто даже не удосужиться взглянуть на вашу надпись, нажмут и все. И все это приводит к тому, что ваша программа переходит с категории утилит в разряд “опасных для системы” - если вдруг в этой “ОС для домохозяек” запустить программку, и не глядя нажать не ту клавишу, а там команда форматирования диска…
Формируется мысль, что если кто-то выучил кнопочки Windows&Office, то он уже может “свободно ориентироваться в современном программном обеспечении”, что естественно в корне неправильно. Но я немного отошел от темы…
Стандартный оконный интерфейс Windows приносит еще проблемы. Как сменить оформление, когда все эти серые кнопочки и ползуночки вместе с курсорами порядком надоели? Всякие “Темы” мало что помогают, а многие из них просто раздражают, и вносят очень большую нагрузку на сознание пользователя - в дополнение к вышеперечисленным “очагам внимания”, следить за которыми все же нужно для работы, сюда добавляются и анимированные курсоры (никак не пойму - зачем?), и звуки, и странные картинки вместо привычных пиктограмм. Для внесения разнообразия в интерфейс разработчикам приходиться очень изворачиваться - довольно удачно эту проблему решили создатели WinAmp, программисты Mozilla пошли путем создания специального языка на основе XML для описания интерфейса своего броузера.
Теперь можно кратко сформулировать основные отрицательные свойства оконного интерфейса а-ля Windows:
* Затруднена работа с несколькими (>3-5) окнами;
* “Когнитивная перегрузка” - когда на экране много как не нужных элементов, так и главным образом тех, которые нужны, и на которых нужно в идеале одновременно концентрировать внимание;
* Применение сложных команд, например при форматировании текста, требует знания что и где нажать, всего пути к нужному пункту меню, да еще и учета того, что сейчас нажато, или было нажато незадолго до этого;
* Большие трудности при смене общего стиля оформления системы;
* Двухмерность интерфейса накладывает определенные ограничения на размещение как документов, так и пиктограмм;
* Стандартизация приводит к автоматическому бездумному переносу принципа “тут нажал - то и то получилось” с одной программы к другой, даже без учета различия между ними;
Ну хорошо, накатил я огромную бочку на все эти окна-окошечка, а что же предложить взамен? В следующей статье я расскажу, что же творится в мире так называемых альтернативных интерфейсов.
При подготовке данной статьи использовались:
* Андрей Зубинский - Первый шаг: от “чайника” - в Unix, Компьютерное Обозрение #29/2000 (рис. 7).
* Андрей Зубинский - Plan9 - гость из другого мира, Компьютерное Обозрение #26/2000 (рис. 4).
* Также выражаю благодарность Сергею Свердлову за скриншот и сам дистрибутив системы Oberon.