MatStyle.info

Только что нашёл у себя в исходящей почте занятное (хоть и весьма пространное) рассуждение о развитии пользовательского интерфейса. Текст написан в сентябре 2007 года для участников проекта Unified Environment.

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

Аппаратные возможности тех времён далеко не всегда позволяли осуществить графический вывод изображений при помощи пикселей, поэтому было найдено неплохое (хотя и паллиативное) решение в виде текстовой псевдографики.
Ярким примером является файловый менеджер Norton Commander, который уже третий десяток лет является законодателем моды на подобные интерфейсы. В это же время появились и первые рабочие примеры "настоящего" GUI (Xerox PARC Star, 1977; Apple, 1984).

В настоящий момент основной парадигмой GUI стала парадигма Окон на Рабочем Столе. Англоязычным людям такая парадигма известна как WIMP - Windows, Icons, Menus, Pointing device. Причин популярности такой парадигмы достаточно много. Во-первых, прямоугольные элементы было проще программировать, а то или иное сходство с известным миром облегчало обучение использованию интерфейса пользователями. Уже много лет устойчиво применяются пиктограммы с изображением дискеты, чистого листа и корзины для мусора. Правда, на этом список стандартных пиктограмм практически заканчивается, но это уже тема другого разговора.

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

С ростом аппаратных мощностей стала наблюдаться устойчивая тенденция к увеличению размеров экрана и, следовательно, доступного для отображения GUI пространства. С одной стороны, это диктовалось удобством работы с новыми приложениями, каковые в силу роста функциональности требовали больше места для отображения и элементов управления, и обрабатываемых данных. Особенно это заметно в приложениях для видеомонтажа, компьютерной вёрстки и редактирования изображений; впрочем, даже современные среды разработки ПО стали заметно более требовательными к доступному на экране пространству.
Так, известный многим Borland Turbo Pascal прекрасно работал в текстовом режиме 80х25 (аппаратное разрешение монитора составляло 640х480, фактически достаточно было отображать 640х200 пикселей, правда, не квадратных), а современной IDE, такой как Microsoft Visual Studio 2008, на экране в 17' с размером 1024х768 пикселей уже откровенно тесно.

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

Интересно представить возможные последствия роста размеров экрана. Для начала следует заметить, что линейный размер элементов GUI практически не изменился. Судя по тому, с какого расстояния пользователи обычно рассматривают изображение на экране монитора, угловой размер элементов GUI тоже изменился незначительно. Вместе с тем угловой и линейный размеры самого изображения увеличились весьма заметно: если лет 12-15 тому назад изображение размером 640х480 считалось нормой, то сейчас редко встретишь изображение меньше, чем 1024х768.
Изображение, а следовательно, и доступное пространство на экране в ширину и в высоту увеличилось более чем в полтора раза. 1024х768 - типичный размер экрана CRT-монитора 17', типичный размер экрана 30' - 2560х1600, то есть изображение в 2,5 раза шире и вдвое выше. В этом случае недостатки существующей парадимы GUI станут серьёзным препятствием на пути её дальнейшего использования.

Почему это произойдёт? Для начала следует обратить внимание на то, как пользователь взаимодействует с GUI, соответствующем парадигме Окон на Рабочем Столе. Важнейшим аппаратным средством в такой парадигме является мышь, в ней-то и скрыты многие проблемы. Мышь позволяет пользователю непосредственно манипулировать элементами GUI, указывать фокус внимания пользователя (выделение), кроме того, мышь — многофункциональный командный инструмент. Сейчас же нас больше всего интересует мышь как указатель и манипулятор. Хотя пространство для движения мыши теоретически ничем не ограничено, обычно амплитуда движений мыши не превышает половину ширины ладони в стороны и 3-4 сантиметра вперёд-назад. Эти значения не случайны: пользователи обычно используют для движения мыши только кисть, а дальше лучезапястного сустава рука с мышью практически неподвижна.

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

Таким образом, при увеличении линейных размеров экрана в 2-2,5 раза использование мыши становится весьма затруднительным. Можно сократить потребные перемещения указателя мыши, перестав растягивать окна на весь экран. Можно и увеличить размер элементов интерфейса, тогда по ним будет проще попасть. Однако это не всё. Например, возникает проблема навигации между окнами, поскольку в традиционных интерфейсах удобных инструментов для этого не предусмотрено. Например, в Windows XP для навигации между окнами кроме возможности указать нужное окно мышью придуманы Панель задач и сочетание клавиш Alt+Tab.

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

Сочетание клавиш Alt+Tab в известных мне реализациях GUI сделано неудобно, поскольку предполагает линейное пролистывание списка приложений, тогда как ничто не мешает списку приложений быть очень длинным. Более того, выбрать 1 нужную кнопку из 11 ненужных на Панели задач по-моему даже проще, чем последовательно пролистать список такой же длины. Общая картина такова, что, хотя оконный интерфейс и допускает полноценную работу с клавиатурой, клавиатура — не основной рабочий инструмент и потому не самый удобный.

У WIMP-парадигмы имеется и другой недостаток. Связан он с доступом к файлам. Сначала небольшая предыстория. Во времена внедрения первых GUI (Apple, 1984) в руководстве пользователя специально для непривычных к GUI людей указывалось, что пиктограммы - это представление файла, однако уже тогда было замечено, что представление стало сущностью, а сущность — представлением. Джон Сиракуза/John Siracusa отмечает: "...to the surprise of many, users very quickly discarded any semblance of indirection. This icon is my file. My file is this icon. One is not a "representation of" or an "interface to" the other." (см. http://arstechnica.com/articles/paedia/finder.ars/3)

Итак, пиктограмма для пользователя являет собой сам файл. Сложность, однако, заключается в том, что уже больше двадцати лет в большинстве систем практикуется доступ к иконкам по признаку их физического (не в качестве массива байт, а в качестве логической сущности) расположения на носителе, тогда как для пользователя такое представление, в общем-то, смысла не имеет. Пользователю значительно более полезным представляется разделение файлов по его собственным, пользовательским логическим категориям. У аккуратных пользователей это разделение и наблюдается: музыка в одной папке, документы в другой, картинки в третьей. Показательно, что программы вроде AmaroK или Google Picasa аналогичным образом освобождают пользователя от необходимости помнить, где и что у него лежит. Ручное структурирование логических сущностей заменяется их автоматическим структурированием и поиском, что при растущем количестве сущностей представляется единственно правильным решением; яркий пример тому - Gmail.

Итак, GUI в традиционной на нынешний момент концепции WIMP рискует столкнуться со следующими проблемами:
1. Сложность использования мыши при больших размерах экрана (пункт "Pointing device") 2. Необходимость физического структурирования логических сущностей по пользовательским категориям, привязка глобальной логической структуры данных к физическому их размещению (пункт "Icons").
3. Неудобство пользования традиционными окнами при их большом количестве и на больших экранах.

Выходов из сложившейся ситуации существует довольно много. По отдельности они едва ли смогут решить все проблемы, но комплексный подход в грядущей ситуации имеет смысл. Проблему окон на большом экране, вероятно, следует решать при помощи концепции неперекрывающихся окон. Достаточно доступно преимущества такой концепции изложены на ресурсе (http://nooface.net/articles/05/01/07/2054240.shtml Nooface).

Проблема структурирования файлов может быть переложена на компьютер, правда, с этим не всё просто. Представляется логичным наличие у логических сущностей неких метаданных, позволяющих надёжно автоматизировать процесс структурирования. Иначе говоря, программа структурирования должна знать, как именно структурировать данные для пользователя. Этот вопрос ещё нуждается в дополнительном исследовании, но едва ли он является принципиально неразрешимым. С одной стороны, необходимы надёжные аппаратные устройства, позволяющие не терять данные; это наводит на мысль о росте популярности RAID-массивов. С другой - требуется система, абстрагирующая пользователя от физического хранения данных и следящая за ссылочной целостностью: ссылки на данные всегда должны указывать на сами данные.
Структурировать данные по пользовательским категориям в такой схеме должен сам пользователь, тогда как структурировать данные по их типу должна система. Также необходимо предусмотреть механизм описания типов, вероятно, доступный также и пользователю.

Наконец, проблема непосредственной работы с окнами уже имеет реализованные решения (dwm, Ratpoison, StumpWM, TrsWM, wmii, XMonad, larswm, ion и т.п.).

Один из первых GUI от Apple:
:

larswm:

wmii: