Назад в раздел
Этот мерзкий, неудобный, противоестественный оконный интерфейс
|
div.main {margin-left: 20pt; margin-right: 20pt}
Этот мерзкий, неудобный, противоестественный оконный
интерфейс
Эта статья построена в форме диалога. Подавляющее
большинство вопросов и возражений были высказаны реальными людьми при
обсуждении этой темы лично или по электронной почте (исключение - некоторые
связующие реплики). Некоторые из аргументов могут показаться специально
придуманными для того, чтобы их можно было легко и эффектно опровергнуть, но
это не так - человеческая глупость не знает пределов ((c) Козьма Прутков), и
если одному что-то очевидно, то другому это придется долго
растолковывать. В статье рассуждения о таких
наглядных вещах, как окна фиксированного (неизменяемого) размера, соседствуют
с анализом эргономики интерфейса и с разбором внутреннего устройства
операционных систем и графических оболочек вплоть до фрагментов ассемблерного
кода. Это объясняется тем, что оконный интерфейс является частью системы
"человек-компьютер" и влияет на работу множества связанных с ним систем,
которые приходится затрагивать в статье для полноты картины.
Мне не
нравятся оконные системы. Не только потому, что они медленно загружаются (есть
такие, которые загружаются быстро), не потому, что жрут ресурсы машины (есть
довольно экономные, по крайней мере по сравнению с остальными), не потому, что
часто рушатся и требуют долгой нудной инсталляции (есть довольно стабильные и
даже вообще зашитые в ПЗУ). Просто графический оконный интерфейс, по моему
скромному мнению, - неудобный, в большинстве случаев ненужный, а часто просто
вредный. И я могу доказать это... ну, по крайней мере, попробовать
доказать.
Речь идет о Microsoft
Windows?
Хотя большинство примеров взято из 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 для перехода из режима
пользователя в режим супервизора и обратно придется закрывать все приложения и
выходить из системы с разрывом всех связей).
А как же
такие удобные вещи, как point&click (укажи-и-щелкни) и drag&drop
(перетащи-и-брось)?
Большинство пользователей считают, что
это удобно и естественно - просто потому, что не знают о более удобных
способах общения с машиной и не задумываются, почему им приходится делать
множество движений для выполнения элементарных операций. Вместо того, чтобы
нажать комбинацию клавиш или набрать команду, мне приходится продираться
сквозь бурелом многоуровневых менюшек, каждый раз целясь мышкой в узкую
полоску нужного мне пункта. Я должен помнить не только название нужного мне
пункта (с такой же легкостью я бы запомнил команду), но и название пунктов по
пути к нему. Неужели кто-то называет это облегчением работы?
Иногда мне
хочется скопировать с экрана какой-то текст, например, из заголовка окна, из
диалогового окна с сообщением об ошибке или из списка установленных системных
шрифтов.
Это еще зачем?
Иногда
требуется. Например, я хочу послать кому-то вопрос или совет о том, что делать
в тех или иных случаях, и надо описать конфигурацию, в которой та или иная
программа работает (или не работает). Короче, я хочу скопировать текст,
который я вижу на экране. Однако, по крайней мере, программы MS-Windows
позволяют копировать только то, что считают нужным. То, что они считают
нужным, а не я! (Можно, конечно, копировать изображение экрана - это имеет как
свои плюсы, так и минусы. В данном случае я говорю о тех данных, которые
программа передала Windows Manager в виде текста, но которые нельзя
скопировать как текст.)
Кроме того, система "наглядного копирования"
имеет ряд подводных камней. Например, если я перетаскиваю мышкой выбранный
файл из одного окна File Manager в другое, это, очевидно, указание копировать
(или, может, перемещать?) файл. Но если я перетаскиваю его в текст
какого-нибудь текстового редактора, то что должно быть помещено в текст - имя
файла или его содержимое? А если содержимое - то оно должно быть вставлено как
есть или должна быть создана ссылка на файл как включенный (многие системы
умеют работать с такими ссылками - это позволяет внести изменения в
какие-нибудь реквизиты и быть уверенным, что обновились все документы,
использующие эти реквизиты). А если это запускаемый файл (интерпретируемый
скрипт), то, может быть, надо поместить результат его работы - все, что будет
выведено на стандартный вывод (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 можно было
запомнить область карты - малополезное свойство, ведь в любую точку карты
можно было попасть, ткнув в нее мышкой.
В оконных интерфейсах нет и
намека на возможность восстановить даже последнее выделение после его
отмены.
Совершенно неудовлетворительно разработана
концепция ClipBoard (буфера обмена).
Как и в
"drag&drop", через буфер обмена могут передаваться данные самых разных
типов. Когда я помечаю файл и копирую его в буфер, что на самом деле
копируется - имя файла, содержимое, обозначавшая его иконка, ссылка на файл? И
что должно вставиться по команде "вставить"?
Разные программы работают
с разными форматами данных; преобразование из одного формата в другой зачастую
совершенно неоднозначно. Из Netscape Navigator в Word копируется только текст
без шрифтов, зато с переводами строк там, где они были визуально; Internet
Explorer гораздо лучше интегрирован с MS-Office, но попробуйте загрузить в
Explorer страницу, скопировать в Word, сохранить на диск, а потом сравнить -
Word внесет от себя много нового! Домашнее задание: попробуйте вставить через
буфер Web-страницу в Excel и сообщите мне о результате.:-)
При
копировании новой порции в буфер старое значение пропадает. Мне говорили, что
можно как-то сохранять историю буфера и даже редактировать его содержимое, но
показать не смогли.
Буфер обмена хорош, когда надо работать с
однородными данными - например, только с текстом или только с растровой
графикой. Когда встречаются разные форматы - жди проблем, потому что у каждого
программиста свое мнение о том, как преобразовывать форматы, причем обычно не
совпадающее с мнением пользователя и других программистов.
Выбор из
пунктов меню может показаться легче, чем запоминание команды, но только до тех
пор, пока этот выбор ограничен некоторым разумным пределом или очень хорошо
структурирован. Хорошо структурированных систем я в своей жизни почти не
встречал - наверно, просто очень мало вещей легко поддаются структуризации, а
непомерно распухшие древовидные списки делают поиск нужного мне пункта просто
мучительным. Конечно, если я сам создавал это дерево и уже долго работаю с
ним, то я буду легко ориентироваться в нем; но что делать, если я должен
что-то сделать на чужом компьютере? Заставить хозяина стоять
рядом?
Сложность меню определяется приложением. Если программа плохо
спроектирована, это ее беда, а не беда оконного интерфейса.
Трудно
сказать, кто виноват, но факт остается фактом - в оконных программах меню, как
правило, менее удобное, чем в текстовых. На мой взгляд, дело тут именно в том,
что современные оконные среды предлагают неудобные стандартные элементы, а
программисты из этих плохих кирпичей лепят плохое здание. Стандартный элемент
предлагает сделать подменю, и программист с удовольствием выносит ряд пунктов
в подменю, вынуждая пользователя делать два щелчка мышкой вместо
одного.
Программист прав - эти пункты по смыслу надо объединить в
некоторый содержащий их контейнер. Виноват интерфейс, который неудобно для
пользователя работает с древовидным представлением информации.
В
отличие от команд, которые надо запоминать, пункты меню все время перед
глазами. В этом смысле меню является самодокументированным.
Это
справедливо, только если меню целиком показывается на экран или хотя бы имеет
не более двух уровней. На самом деле простой пользователь регулярно пользуется
всего десятком команд, которые вполне можно запомнить или выписать на листик и
повесить рядом с монитором. Обратите внимание: рядом с монитором - там
шпаргалка не займет драгоценной экранной площади, а бумага, в отличие от
монитора, стоит гораздо дешевле и не дает вредных излучений.
Можно подумать, что в текстовых приложениях нет
подменю.
Разумеется, система меню - не привилегия оконных
систем, многие программы реализуют меню и в текстовых режимах. Просто в
оконных системах меню гипертрофировалось до совершенно невозможных размеров,
когда удобство выбора из представленного списка заслоняется проблемой поиска в
дереве. Меню не является однозначно плохим стилем, но прежде всего, чтобы быть
полезным, оно должно быть хорошо организовано (как в смысле составления, так и
в смысле программы, осуществляющей менюшный интерфейс); а главное -
составителям меню следует знать меру и проявлять минимум заботы о
пользователе.
Ну а чтобы вбить последний гвоздь в гроб древовидного
представления данных, рассмотрим, как бы выглядел поиск этой статьи, если бы
ее 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 способны помочь
пользователю в поиске сайта по наиболее очевидным критериям, но все-таки их
применимость, по крайней мере, для меня, довольно ограничена хотя бы в силу
того, что составители рубрик недостаточно разбираются в интересующих меня
областях.
Продолжение в следующем (и в следующем, и в
следующем) номере.
Дмитрий Карпов |
|
 |
|
