Я разобью свои замечания на два раздела: замечания по
конкретным высказываниям автора и замечания о статье в целом. По-моему
удобнее будет текущие замечания высказывать по ходу текста, а общие - в его
окончании.
Во-первых давайте дадим ряд вводных определений для
фиксации темы обсуждения.
- Интерфейс - совокупность электрических, механическиз и программных средств,
позволяющих соединять между собой элементы автоматической системы обработки
данных.
("Справочник разработчика АСУ", Москва, "Экономика", 1978, стр. 555)
- Интерфейс пользователя - технология реализации диалога "человек-ЭВМ".
( (c) Сергей Середа, 28/10/2000)
- Окно - логически обособленная область экрана ЭВМ, которой ограничивается
ввод/вывод определенного приложения.
( (c) Сергей Середа, 28/10/2000)
- Параметры окна - набор характеристик, определяющих представление окна при
диалоге с пользователем. Примерами параметров могут служить координаты
вернего левого угла окна, высота, ширина окна, перемещаемость окна, наличие
специальных элементов управления, способ перемещения окна и др.
( (c) Сергей Середа, 28/10/2000)
- Система окон - совокупность логически взаимосвязанных окон, обладающая
способностью манипулировать параметрами своих составляющих, а так же
возможностью перемещения из окна в окно.
( (c) Сергей Середа, 28/10/2000)
- Оконная библиотека - внутренне согласованный набор модулей и подпрограмм,
реализующий систему окон.
( (c) Сергей Середа, 28/10/2000)
- Оконный интерфейс - интерфейс пользователя, основанный на использовании
систем окон.
( (c) Сергей Середа, 28/10/2000)
- Оконная операционная система - операционная система, включающая оконный
интерфейс как стандартный интерфейс пользователя. При этом ядро ОС
содержит оконную библиотеку.
( (c) Сергей Середа, 28/10/2000)
Я сам дал вышеуказанные определения, так как под рукой
просто не оказалось современного справочника, охватывающего данную
предметную область.
А теперь, давайте рассмотрим ближе высказывания автора
по ходу текста.
"Нельзя говорить об оконном интерфейсе, не затрагивая недостатков отдельных
реализаций; более того, общие недостатки всех реализаций часто вовсе не
являются непреодолимым недостатком оконного интерфейса."
Я не согласен с первой частью этого предложения, так как
немного ранее автор пишет, что считает оконный интерфейс неудобным в принципе.
Отсюда следует вывод, что автор нашел концептуальные недостатки в данном виде
интерфейсов.
Суждение же о принципе на основе его реализаций немного
напоминает небезызвесный анекдот, в котором человек называет Паваротти
бездарностью, потому что этому человеку друг напел арию, исполняемую
указанным оперным певцом.
Разумеется, не будем забывать о таком методе познания как
индукция, но для индукции необходим представительный ряд однотипных наблюдений,
которых в данном случае нет в силу разнородности реализаций оконного
интерфейса.
В силу вышеуказанного соображения многие доводы автора
превращаются в обычную оценку конкретных реализаций принципа (например,
обсуждение модальных окон).
"Я лишь утверждаю, что значительную часть задач можно и должно решать на базе
других, более простых и эффективных средств."
Абсолютно согласен с данным утверждением.
"... я уверен, подавляющую часть времени его целиком занимает задача в
полноэкранном режиме.
Если Вы работаете с несколькими задачами, Вы переключаетесь
между ними - но каждая из них все-таки будет занимать экран целиком."
Далеко не однозначное утверждение. Оно верно лишь в случае,
если читатель статьи - секретарша, знакомая лишь с редактором Word и игрой
Tetris. В более же общем случае использование нескольких окон на экране
одновременно - далеко не редкая вещь.
"Когда открывается окно диалога, я переключаю свое внимание
на него; более того - обычно (по кр.мере в MS-Windows) эти окна модальные,
т.е. я не могу ничего делать с породившим их окном, пока не закрою модальное."
Так именно для этой задачи окна диалога и созданы. Какой же
смысл вызывать окно, если вы не собираетесь переключать на него внимание? А
запрет на работу с окном-родителем во время активности порожденного окна
соответствует принципам обработки данных (пока вы не закончили настройку,
программа просто не знает, как ей себя вести), другой вопрос, что модальные
окна в Windows несовершенны, а так же что некоторые программисты черезчур ими
увлекаются.
Относительно полноэкранных диалогов, тут ничего невозможного
нет, но пока есть вероятность ситуации, в которой пользователю необходимо
одновременно видеть и диалог и еще одно окно или Рабочий стол (хотя бы
заурядный Help при настройке системы) будут аргументы в пользу оконных
диалогов.
"Достаточно посмотреть, сколько времени у пользователя уходит
на то, чтобы красиво расположить окошки, чтобы стало понятно - оконный
интерфейс не только не облегчает работу, но и забирает рабочее время,
которое могло бы быть потрачено с большей пользой."
Ну, во-первых здесь многое зависит от пользователя, обычно
переставлением иконок на Рабочем столе занимаются от откровенного безделья,
функциональное же упорядочение иконок занимает минимум времени. Во-вторых
данный довод применяется и к ЭВМ в общем и к телевидению и ко многому другому.
(Вот, дескать, человек целыми днями телевизор смотрит/на компьютере работает,
а мог бы делом заниматься).
"Поиск в ворохе набросанных на экране окон или среди сваленных в беспорядке
иконок - отличный способ убить впустую значительную часть рабочего времени.
Практически вся полезная работа производится в полноэкранном режиме
какой-либо программы, а ссылки (shortcuts) на программы или документы лучше
всего хранить в упорядоченном списке."
Хочу обратить ваше внимание, что при большом количестве
открытых окон/запущенных проиложений их графическое отображение вырождается
как раз в простой список задач, выбор нужной задачи в котором и приносит
максимум неудобств.
А ссылки на программы и документы, по крайней мере в
Windows 9.x/NT4+, и организованы в упорядоченный список, это - небезызвестное
вам меню кнопки "Пуск".
Так же к организации "Рабочего стола" вполне применимы
принципы необходимости и достаточности (которые нарушены, опять же, в
реализациях).
Разговор о "письменных столах с раз и навсегда
привинченными к ним канцелярскими приборами" некорректен, если речь идет об
универсальных ЭВМ, так как в этом случае "привинчивание" ведет к потере ЭВМ
гибкости, а следовательно и универсальности. В случае же специализированных
ЭВМ встраивание ОС, интерфейсов, ПО и т.п. является вполне естественным
способом снизить системные требования ЭВМ.
"Если программа, с которой я работаю, удобна, ничего другого мне и не надо,
а если нет - окна не помогут."
В целом, утверждение верное, но обычно окна помогают (там,
где они действительно нужны).
Совершенно согласен с тем, что многозадачность и
многооконность - абсолютно разные и взаимонезависимые вещи, обычно
связываемые между собой неспециалистами.
Тем более непонятно, почему автор начинает углубляться в
аспекты многозадачности UNIX-систем. Хотя описание виртуальных консолей,
разумеется, имеет отношение к интерфейсам.
Относительно Apple Newton Message Pad, справедливо
сказанное мной выше относительно универсальных и специализированных ЭВМ.
Относительно Drag'n'Drop и Point'n'Click опять же - идея
неплохая, а реализация оставляет желать лучшего, кроме того не оговорены
условия применения указаных технологий.
"Иногда мне хочется скопировать с экрана какой-то текст, например,
из заголовка окна, из диалогового окна с сообщением об ошибке
или из списка установленных системных шрифтов."
Проблема копирования с экрана связана с графическим
интерфейсом, а не оконным. Копирование любого элемента экрана в текстовом
режиме не представляет проблем, так как в видеопамяти хранятся коды символов
(даже при многооконном интерфейсе, например в OS/2 2.x). В графическом же
режиме (который, разумеется, используется графическим интерфейсом) видеопамять
содержит коды точек, из которых состоят все элементы интерфейса (в том числе
и символы), таким образом скопировать элементы интерфейса можно либо при
помощи самого приложения, выводящего информацию на экран, либо придется
использовать систему графического распознавания полученной вами "фотографии"
экрана.
"Кроме того, система "наглядного копирования" имеет ряд подводных камней.
Например, если я перетаскиваю мышкой выбранный файл из одного окна FileManager
в другое, это, очевидно, указание копировать (или, может, перемещать?) файл."
Совершенно разделяю мнение автора по данному вопросу, но
не совсем понимаю, какое отношение это имеет к оконному интерфейсу? В том же
FileManager, например, можно работать в полном экране с одним файловым окном
(что, кстати, является стандартом для Windows) и использовать "наглядное
копирование".
"Во многих программах используется очень неудобная система выделения.
Например, в Word, Write и Notepad можно выделить один кусок текста,
а в Excel и DOS-окне - один прямоугольный блок."
Согласен с существованием неудобств с выделением текста в
программах Windows, но опять же не вижу связи с оконным интерфейсом. Например,
"прямоугольное" выделение текста успешно реализовано в DosNavigator, который,
тем не менее, успешно использует оконный интерфейс (TurboVision), справедливо
считающийся очень большим плюсом этого менеждера файлов по сравнению, например,
с Norton Commander (кстати, Norton, в свою очередь, является первым
приближением к оконному интерфейсу, так как его экран уже состоит из двух окон,
содержимое которых можно менять независимо друг от друга).
То же относится к сетованиям автора на другие недостатки
ПО под Windows.
Концепция буфера обмена Windows XX основана на
Объектно-ориентированном подходе, таким образом, объект-получатель сам знает,
что делать с объектом в буфере. Разумеется, и сама концепция и реализация
буфера далеко не идеальны.
"Трудно сказать, кто виноват, но факт остается фактом - в оконных
программах меню, как правило, менее удобное, чем в текстовых."
Во-первых, хочу заметить, что система меню не имеет ни
малейшего отношения к оконному интерфейсу и может одинаково успешно/безуспешно
использоваться как в полноэкранном интерфейсе, так и в оконном.
Во-вторых, "противопоставление оконных программ текстовым"
- это "противопоставление арбузов космическим кораблям", так как понятия
"оконный интерфейс" и "текстовый режим" находятся в совершенно разных
классификационных группах и не пересекаются, кроме того, как уже писалось
выше, оконный интерфейс зародился именно в текстовом режиме.
Относительно сравнения системы меню и набора команд,
"которые можно запомнить" хотелось бы отметить, что автор забывает о таком
важном аспекте ПО как простота освоения. При помощи правильно организованной
системы меню абсолютно незнакомый с программой пользователь может в считанные
минуты приступить к работе, в то время как без меню пользователь будет
несколько дней учить команды и изучать документацию, прежде чем приступить к
использованию ПО (разумеется чтение документации - вещь совершенно нелишняя
при использовании любых систем и интерфейсов).
Плохая структурированность системы меню во многих
программах существует отнюдь не по вине меню, как средства представления
данных, а из-за нарушения норм на структуру и состав информации в меню (такие
требования существуют в виде ГОСТ-ов и уже очень давно).
Кроме того, полюбившиеся автору гиперссылки так же можно
назвать системой меню или, как минимум, ее развитием. Так же стоит отметить,
что меню не подразумевает, само по себе, представления информации именно в
виде иерархической структуры. Общеизвестно, что существует два метода
классификации: иерархический и фасетный. Применительно к обсуждаемому вопросу,
в стандартной системе меню чаще принято реализовывать иерархические структуры,
а в гиперссылках - фасетные.
Не буду вдаваться в спор об удобстве древовидного
представления информации, но кину небольшой камень. Дело в том, что существует
такая система навигации по Интернет как Gopher, самое смешное в том, что она
как раз реализована как гигантская система меню. Кстати, функционирует она
довольно успешно.
А пример с поиском URL данной статьи приведен некорректно,
так как система меню всегда содержит описания действий, привязанных к пунктам
меню, потому-то Gopher и работает так успешно.
Согласен с автором относительно слабой развитости средств
поиска информации в Интернет, но опять не улавливаю связи с оконным
интерфейсом.
"А в новом интерфейсе, появившемся в Windows'95, файловая система
еще больше утратила связь с реальностью."
Честно говоря, интерфейс не зависит от файловой системы
(например, как упоминал и сам автор, оконный интерфейс реализован в ОС Windows,
OS/2, UNIX, хотя файловые системы у них кардинально различаются). А в данном
случае речь, скорее всего, должна идти о ПРЕДСТАВЛЕНИИ файловой системы, а в
Windows 95 г-ну Гейтсу, очевидно, пришла в голову "гениальная" мысль отойти
от традиционной привязки интерфейса к работе с файлами (не к файловой системе!)
и перейти к работе с объектами, важными для работы пользователя, отсюда и
мешанина в меню Старт.
"Вообще пора скрыть файловую систему от пользователя и даже от многих
программ и предоставлять доступ в терминах не файлового доступа, а доступа
к данным - это освобождает программиста от необходимости разбираться с
форматом хранения данных в файлах и позволяет разнести вычисления на разные
машины в архитектуре "клиент-сервер"."
Вот именно это и попытались воплотить в Windows 95
"разработчики" Microsoft. Но автор с ними, очевидно, друг друга недопоняли :-).
"У программиста есть два пути:
- дать пользователю доступ к системе в том виде, в каком имеет
доступ программа просмотра, и в этом случае пользователь
должен копаться в особенностях файловой системы;
- скрыть от пользователя файловую систему и вместо нее подсунуть какую-то
другую структуру, возможно, базирующуюся на файловой (примерно как это
делается в WWW) - это требует абсолютно четкой работы промежуточного
слоя, что возможно лишь в клиент-серверной архитектуре, где никакой
программе (за исключением ЧП) не дозволено лазать в обход сервера
(примерно как никто не лазает на диск в обход файловой системы)."
Оба этих пути реализованы в большинстве современных ОС,
если опять упереться в Windows, то прямой доступ к диску дается только
системным компонентам - VxD, SYS (хочется в это верить:-), а "клиент-серверный"
доступ реализован в знаменитом Win32API, причем на уровне программного
интерфейса программист работает со стандартным потоком данных, вне зависимости
файл это или данные из локальной сети или модема.
"Нормальные люди общаются с использование устной и письменной речи; так
почему же с компьютером мы вынуждены общаться посредством иконок? Неужели
создатели оконного интерфейса считают пользователей компьютера неграмотными
тупицами? Зачем вместо текста нам предлагают картинки? Картинки хороши,
когда их мало, но в куче набросанных картинок найти нужную гораздо сложнее,
чем вызвать нужный объект по имени. К тому же все равно приходится читать
подписи под картинками либо заучить их наизусть."
По поводу картинок я не согласен, так как мышление у
человека (если оно вообще есть :-) является образным, ассоциативным. Если
немного углубиться в историю, то всех нас можно назвать безграмотными
тупицами, так как все письменные знаки (текст) произошли именно от картинок,
изображающих объекты или действия. А человек все-таки мыслит образами.
В качестве упражнения поставьте у всех приложений на
Рабочем столе одинаковые иконки (например стандартный сине-белый квадратик
неизвестного приложения) и посмотрите, насколько вам сразу станет проще без
этих отвратительных иконок.
Другой вопрос, что должен быть утвержден неизменный ряд
знаков (иконок), отражающих стандартный набор действий пользователя и ЭВМ
(как это сделано, например, в представлении алгоритмов при помощи блок-схем).
Конечно, когда в каждой новой версии/подверсии программы полностью меняется
набор иконок, разумеется, эффект оказывается отрицательным.
"Современные оконные системы норовят запомнить все что только можно."
Более корректно было бы написать "современные системы
норовят запомнить все, что только можно". Я бы сказал даже больше,
современные программы даже пытаются украсть у вас эту информацию. Но не стоит
путать политику с технологией. Сейчас вторжение в частную жизнь поощряется
корпорациями, но этот печальный факт никак не относится к оконному интерфейсу
в целом. (Правда, оконный интерфейс имеет отношение к финансовому взлету
фирмы Microsoft и ее сегодняшнему доминированию на рынке ИТ, но в этом нет
прямой вины интерфейса).
"Представление объектов в графическом виде всегда будет вторично по
отношению к текстовому. Начнем с того, что имена можно упорядочить по
алфавиту, а как упорядочить картинки? А если надо объяснить человеку,
куда нажать, то как обрисовать картинку - перечислять содержимое? Все
равно у каждого объекта будет имя и это имя придется запомнить, а
иконка - лишь вспомогательное средство."
Категорически не согласен с автором, объяснение уже дано
выше. Что касается упорядочения, то наиболее разумным является упорядочение
по функциональному признаку, а он к алфавиту не имеет никакого отношения.
Относительно дорожных знаков, а что плохого в том, что не
только до водителя, но и до оператора ЭВМ все будет быстро доходить? И опять
же, если вернуться к восприятию человеком графической и текстовой информации,
человек восринимает информацию абсолютно отлично от компьтера. Компьютер
работает только с формализованной информацией, поэтому текст для компьютера
более приемлем чем изображение, у человека же все наоборот, он напрямую
воспринимает картины на изображении, поэтому иконка "считывается" человеком
на порядок быстрее чем текст, который нужно распознать и перевести на
внутренний для человека язык образов. Поэтому графическое представление
некоторых частей интерфейса ведет лишь к повышению производительности труда
оператора ЭВМ.
Несомненно так же, что злоупотребление иконками (как и
всем остальным в этой жизни) ведет к негативным последствиям.
Автор оставляет без ответа вопрос о независимости иконок
от языка ОС и программы и переходит на критику системных шрифтов Windows.
Можно предположить, что это сделано из-за отсутствия у автора аргументов по
этому вопросу либо автор просто опять отвлекся от обсуждаемой темы.
"И легко заметить, что чем более "оконной" делается система,
тем неповоротливее и прожорливее к ресурсам она получается, а увеличение
количества "наворотов" делает систему неудобной для пользования."
Здесь автор несколько заблуждается, система становится
более прожорливой к ресурсам не когда она становится "более оконной", а когда
она становится "более графической". Таким образом, автор ищет дьявола не
совсем там где нужно.
Идея автора о полезности применения кадров вместо окон
является довольно ценной и при достаточной ее проработке можно достичь
неплохих результатов, боюсь, правда, что заменить оконный интерфейс не
удастся. От себя хочу отметить, что в отличие от окон, которые обычно
организованы в виде двунаправленного полносвязного списка, кадры требуют
значительно меньше ресурсов. Тема эта замалчивается ведущими производителями
ПО из-за необходимости разрабатывать новые стандарты и библиотеки, чем они
категорически не хотят заниматься.
"Это легко объяснимо: трудно наглядно указать, как именно мы хотим
расположить фреймы. Операция, элементарно выполняющаяся редактированием
frameset'а, становится невообразимо тяжелой при попытке реализовать ее
перетаскиванием."
По моему мнению для "визуального" управления кадрами
необходимо просто создать специфический элемент управления (например для
поворота кадра на 90').
Относительно мыши - сугубо индивидуальная неприязнь автора
к манипулятору "мышь" не играет совершенно никакой роли в ее объективной
характеристике. Кроме того, мышь - обязательное следствие графического
интерфейса (не обязательно оконного), как решение проблемы оперативной
навигации по графичесму экрану.
"В конце концов, все произведения литературы и живописи были сделаны именно
так, а внедрение компьютеров и мышей что-то не дало всплеска талантливых
произведений! :-)"
Согласен с автором, но, вообще-то, ЭВМ это - Электронные
Вычислительные Машины, а не электронные Бетховены, Ломоносовы и Да Винчи. :-)
Электронное перо - вещь хорошая, но, в основном, оно
применяется для ввода рукописных текстов или рисования, принципиально же оно
ненамного отличается от мыши.
Отличие "чувства клавиатуры" от "чувства мыши" заключается
в простой вещи: клавиатура является дискретным устройством управления, а мышь -
дифференциальным. Особенно наглядно это провляется в системах радиоуправления
различными приводами (например, в авио- или автомоделировании, если кто в
детстве занимался).
По поводу двойного щелчка - это намного более простая
задача, чем научиться печатать на клавиатуре "вслепую".
Автор совершенно справедливо описывает недостатки
существующих реализаций оконных систем, но причина недостатков, скорее, пока
не регресс, а отсутствие прогресса, стимулируемое в том числе и фирмой
Microsoft.
"В то же время в Solaris можно активизировать и двигать окно, не вызывая его
наверх - это свойство как раз полезно в тех случаях, когда надо видеть одно
окно, а работать в другом."
Самое смешное, что такой механизм предусмотрен и в Windows,
но, как и многое другое в этой ОС, он деактивирован.
Обзор различных реализаций интерфейсов в разичных ОС
говорит о большом опыте автора по работе в таких системах, что во многом
объясняет его приверженность к командной строке и неприятие оконного
интерфейса. Но личная приязнь/неприязнь - еще не повод для построения
суждений о "ненужности" чего бы то ни было, предоставим людям самим решать,
что им нравится, а что - нет.
" А если мне надо держать перед глазами два документа? Да еще в разных
программах?
А зачем? Если подумать, то окажется, что любая необходимость видеть
два документа одновременно есть следствие недостаточной автоматизации
либо непродуманного интерфейса. Либо нужные мне данные можно
скопировать в редактируемый документ и там уже править, либо человек
выполняет работу, которую мог бы выполнить компьютер."
Могу сразу привести контрпример:
Я только закончил работу по переводу документа, при этом (будьте внимательны)
а) Исходный документ записан в формате Acrobat PDF
б) Перевод редактируется в редакторе программы DosNavigator
в) Неплохо было бы видеть и электронный словарь (Сократ, например)
И все это одновременно на экране (ну, как минимум исходный текст и перевод).
Если вы попробуете возразить и сказать, что проблема
решается последовательным перепрыгиванием из одного экрана в другой, вас
убьет первый же переводчик текстов :-).
Кроме того этот пример далеко не единственный (а как насчет
отладки программы или редактировании HTML-страницы и т.п. ?)
А кроме этого, чтобы читателю было наиболее удобно
разбираться в моей критике статьи г-на Карпова, ему придется открыть в одном
окне текст вышеупомянутой статьи, а во втором - мою критическую статью :)
Все же ответ на этот вопрос существует, необходима
всего-лишь программа-фильтр вывода, которая осуществит запуск и параллельную
работу всех трех указанных в контрпримере приложений, и, сама работая в
полноэкранном режиме, разобьет рабочее пространство на, упоминавшиеся автором,
фреймы (или, по русски - области), в которых и будет выдаваться
отфильтрованный вывод трех программ. Неизвестно, правда, каких ресурсов
потребует эта программа, какова будет сложность ее создания, учитывая
графический вывод информации и удобство пользователя, и будет ли указанная
программа реальной альтернативой "Менеджера окон" ?
"... гораздо логичнее было бы отображать документы - иконки, олицетворяющие
задачу, должны содержать не рисунок задачи (например, стилизованную букву
"W" для редактора Word), а внешний вид документа (той части, которая видна в
рабочем поле редактора), уменьшенный до размеров иконки. То же самое, кстати,
относится и к отображению документов-файлов в FileManager - желательно
изображать их не типом обрабатывающей их программы, а видом титульной
страницы."
Полностью поддерживаю мнение автора, но есть два дополнения:
во-первых, в FileMananger Win98 уже можно видеть титульные страницы ряда
документов, во-вторых, чтобы системная файловая оболочка могла выдавать
вместо иконки уменьшенное изображение содержимого документа, она должна уметь
это содержимое прочитать, таким образом, файлы, форматы и просмотрщики которых
не "зарегестрированы" в ОС, все равно придется отображать какой-то общей
иконкой.
Все вышеописанное, разумеется, не относится к "Панели задач",
по данному вопросу я совершенно согласен с автором.
Очень интересна информация о Hyperbolic Tree.
"Одним из основных недостатков оконного интерфейса является его
прожорливость по отношению к ресурсам."
Вместо ответа приведу слова автора, расположенные
несколькими строками ниже:
"Обратите внимание: как только мы отказываемся от текстового режима и
переходим на графический, немедленно в два, а то и более раз вырастают
потребности в памяти."
Автор, по непонятной мне причине, отождествляет оконный
интерфейс с графическим режимом, хотя ранее в статье он высказывался за отказ
от оконного интерфейса в пользу полноэкранного ГРАФИЧЕСКОГО. Так где же корень
всех зол, в оконном интерфейсе или в графическом режиме?
"В этом смысле очень интересно сравнить взаимодействие программы
с WindowManager'ом и взаимодействие X-терминала с хостом."
В данном случае, доволно интересные суждения автора имеют
прямое отношение к реализации оконных интерфейсов, при этом сама концепция
интерфейса ни в коей мере не затрагивается.
Объектно-ориентированное программирование - не панацея от
всех бед, а способ сократить издержки или просто сделать возможной реализацию
сверхсложных программ, но им еще надо уметь пользоваться.
"А для многих задач коллективной работы с каким-либо набором данных
зачастую достаточно мощного компьютера, к которому подключены дешевые
текстовые терминалы. Существенное преимущество такого подхода - резкое
снижение стоимости всей системы при большом рабочих мест и снижение
загруженности сети."
Абсолютно согласен с автором, но на этих дешевых текстовых
терминалах прекрасно работает, например, Midnight Commander, клон Norton
Commander для Unix-подобных систем, а это уже оконный интерфейс, хоть и
примитивный.
"Не могу не признать, что графический режим полнее использует экранное
пространство: т.к. буква "w" гораздо шире, чем буква "i",
нецелесообразно тратить на них одинаковое пространство, как это
принято в текстовых режимах."
И опять я не согласен с автором, дело в том, что
наиглавнейшей целью любого интерфейса является обеспечениеь удобства
пользователя, а разная ширина знаков на экране утомляет зрение гораздо
сильнее чем одинаковая. Причина, естесственно, в том, что глаз должен
постоянно подстраиваться под разную ширину символов, что и приводит к
утомлению. Правда, мой аргумент достаточно голословен без приведения
экспериментального подтверждения.
Наиболее эффективно было бы вести дискуссию о преимуществах
или недостатках интерфейсов вооружившись биометрическими данными Homo Sapience
и соответствующими требованиями к организации интерфейсов.
В общем случае, а именно так это подается в работе, вопрос
"Что лучше, командная строка или оконный интерфейс?" совершенно идентичен
вопросу "Что лучше, лопата или топор?". Топором тоже можно копать, а лопатой
можно рубить, но почему-то этого никто не делает. Разумеется каждый из видов
интерфейсов более применим в каких-то одних областях и менее применим в других.
Например, можно перефразировать известную поговорку и сказать "Что системному
администратору - хорошо, то рядовому пользователю - смерть".
Если попытаться собрать воедино высказывания автора, то
получится, что оконный интерфейс плох в принципе по следующим причинам:
- Автору не нравится ОС Windows
- Автору не нравится наглядное представление информации
- Автор считает наиболее удобным полноэкранное представление информации
- Автору не нравится реализация ПО под Windows
- Автору не нравится реализация режима диалога в виде меню
- Автору не нравится отображение файловой системы в Windows
- Автору не нравится существующая мода на несанкционированное копирование
персональной информации пользователей
- Автору не нравится повышение системных требований ПО при использовании
графического режима отображения информации
- Автору не нравится манипулятор типа "мышь"
- Автор выступает за эффективное использование аппаратных средств ЭВМ
- Автору известны альтернативные оконному интерфейсы
С большинством из этих пунктов можно согласится как с
личными симпатиями/антипатиями автора, но ни в коем случае не как с доводами
против оконного интерфейса как концепции.
Общий вывод:
К сожалению, автору так и не удалось доказать
несосотоятельность оконного интерфейса. Вместе с тем автор коснулся множества
тем (относящихся и не относящихся к теме обсуждения), а так же высказал ряд
интересных идей.
Опять же к сожалению, автор не показал нам леса за
деревьями (надеюсь, что сам автор этот лес увидел), а все интересные идеи
оказались частично блокированными сумбурным изложением текста.
Так же, по моему скромному мнению, указанный текст нельзя
назвать статьей в научном смысле этого слова, так как материал не
удовлетворяет требованиям к данному классу документов.
Одно из самых главных нареканий - отсутствие четкого
определения основной темы обсуждения (оконного интерфейса), вследствие чего и
возникает максимальное количество разночтений, а так же непонимание автора
читателем.
Кроме того, статья ОБЯЗАТЕЛЬНО должна быть логически
упорядочена (что, в принципе, должно быть естественено для человека, знакомого
с Физикой).
И, наконец, изложение должно быть последовательным,
постепенно подводящим читателя к основному выводу статьи.
Исходя из вышеуказанных соображений, данный текст можно
назвать "материалом" или "мнением автора".
P.S.
Я, лично, отнюдь не являюсь яростным поборником оконного
интерфейса и предпочитаю командную строку, но не в ущерб эффективности работы
на ЭВМ.
Более того, я, ни в коей мере не пытался, в данной критике,
как-то обидеть автора или представить его некомпетентным, основное мое
внимание было уделено структурному изложению текста и "стойкости" аргументов
автора. По моему мнению, после ознакомления с данной критикой автор может
несколько переосмыслить предметную область и значительно укрепить свои
аргументы по данному вопросу.
С уважением,
Сергей Середа
serge_sereda@hotmail.com
