Переход от разработки локальных приложений c «виндоузным» интерфейсом к разработке веб-приложений требует радикальной смены парадигмы. И в этой статье я попытался выделить и описать отличия в подходах к разработке этих двух классов систем и вообще — мое впечатление от веба как «высшей и последней стадии» развития пользовательских интерфейсов.

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

Но сейчас наметилась тенденция к так называемой глобализации информационных систем, то есть переделки «локальных» систем в интранеты. Упомянутой глобализацией сейчас занимаются многие западные фирмы. Соответственно растет число разработчиков веб-систем. Так что эта тема снова актуальна.

Ты помнишь, как все начиналось, или Хорошо забытое старое

На моей памяти, WWW — уже пятое поколение интерактивных интерфейсов.

1 Первыми были терминалы для ЕСовских машин. Но суть их была не в том, что они были большие, железные и алфавитно-цифровые, а в том, что они обменивались с такой же большой и «железной» ЕСкой большими (правда, не «железными») блоками информации — на терминал присылался целиком образ экрана (или даже чуть больше), а обратно, по нажатии специальной кнопочки «Передача», отправлялся тот же образ, только отредактированный.

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

А в промежутке между приемом и посылкой буфера терминалы работали сами по себе — будто никакой ЕСки и нет. Иногда при нажатии кнопки «Передача» оказывалось, что ее (ЕСки) и вправду нет — точнее, физически есть, а логически нет — повисла.

А поскольку использовались терминалы не только (и не столько) для ввода текстов, сколько для структурированной информации (форм), то эти терминалы умели поддерживать формы аппаратно — во входном буфере им определенным образом передавалось описание формы на «птичьем языке», а при передаче с терминала в ЕСку передавался не весь экран, а только содержимое полей формы.

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

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

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

4 Предпоследним и ныне здравствующим поколением являются оконно-формовые интерфейсы типа Windows. Мощность процессоров окончательно победила здравый смысл, все стало рисоваться исключительно в графике, причем масштабируемыми TrueType-шрифтами. Мазохисты, любящие писать в видеопамять или даже использовать базовые примитивы ввода/вывода, доступные в Windows, остались только среди разработчиков игр, причем даже не самих игр, а движков к ним.

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

- окна — самостоятельной прямоугольной области экрана, размером которой управляет пользователь;
- управляющего элемента — квазисамостоятельного прямоугольного элемента в окне с фиксированным размером и координатами.

Причем не потому, что она является единственно возможной и самой удобной, а потому, что ее (как самую простую) поддержали производители базового ПО.

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

И казалось, что так будет всегда, пока не появился веб. Точнее, пока протокол HTTP не начали использовать для построения интерфейса к удаленным системам, а не просто как способ посмотреть домашнюю страничку Васи Пупкина.

5 Время замкнулось, Великий змей ухватил себя за хвост и выяснилось, что по логике работы «сверхтонкий браузер-ориентированный клиент» ничем не отличается от большого железного терминала двадцатилетней давности.

Точно также сервер должен сформировать в текстовом (HTML) виде блок передаваемой пользователю информации, автономное устройство (правда, сейчас это компьютер, а не терминал) должно обеспечить возможность ввода/корректировки информации, и отправить введенную информацию на сервер по нажатию очень специальной кнопки.

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

Отличия и проблемы

Разный принцип работы удаленного (браузерного) и локального (GUI) интерфейсов (да и вообще — приложений) обуславливают совершенно разный подход к их проектированию и разный «look and feel» для пользователя.

Итак, в чем же фундаментальные отличия HTML-интерфейсов от интерфейсов локальных систем?

1 У браузерного приложения сервер находится далеко, и по мелочам его дергать нельзя.

То есть типичные для локального приложения приемы, когда при переходе курсора в какое-то поле идет запрос к базе для выборки данных, совершенно неприменимы в случае браузерных приложений. Т.е. интерфейс должен быть по возможности, автономен, и о загрузке необходимых данных на клиента нужно заботиться заранее. Причем заботиться нужно также о том, чтобы их количество было по возможности минимально…
2 Гораздо более сложное и ограниченное по возможностям программирование «тонкой реакции» на нажатия кнопок.

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

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

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

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

4 В отличие от локальных приложений, браузерные интерфейсы всегда и принципиально многооконны (многосессионны), причем идеология этой многооконности совершенно другая, нежели у типичных GUI-приложений — нет понятия модальных окон, окна реально независимы (нет возможности синхронизировать их содержимое), открываются и закрываются без какого-либо контроля со стороны сервера, и др. Много проблем добавляет разработчикам и кнопка «Назад», которую часто хочется, но не всегда можно заблокировать.

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

Эту многосессионность можно ограничивать средствами сервера, искусственно обеспечивая единый поток управления, но это приводит к крайне неинтуитивно ведущим себя приложениям.

стр. 2>>