GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
Не отключайте правую кнопку мыши!(18781)
Разработка пиктограмм для веб-сайтов(13241)
Функциональное тестирование(11442)
WEB vs GUI - точка зрения разработчика(10110)
Что такое юзабилити?(9834)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » Usability » WEB vs GUI - точка зрения разработчика

WEB vs GUI - точка зрения разработчика


Андрей Акопянц
andrey@akop.ru
http://akop.ru/

Страницы: [ 1 ] [ 2 ]

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

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

В случае веб-приложения все пользователи обслуживаются, как правило, одной задачей (web-сервером и сервером приложений). И этот самый сервер, получив "пинок" от браузера, должен понять - что делать, и какой HTML сгенерировать и отдать этому браузеру.

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

Эту область данных мы будем называть контекстом, а период его существования - от момента входа пользователя в систему до уничтожения контекста - сессией. Контекст идентифицируется либо по имени пользователя, пришедшему в составе запроса, либо по специальному идентификатору сессии, который "гоняется'' между браузером и сервером либо в параметрах URL (вы наверняка видели при работе с разными веб-сайтами в URL что-то типа session_id=ХХХХ), либо в куке.

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

Еще одну проблему создает наличие многооконности и кнопки "назад". Потому как состояние окна браузера, в котором пользователь активирует свой запрос, может оказаться совсем не таким, как ожидается, исходя из состояния данных в его контексте. Поэтому иногда последовательность жестко ограничивают, передавая не только идентификатор сессии, но и временной штамп, обновляемый при каждом запросе, и при получении "устаревшего" штампа отказывая в обслуживании запроса, и/или принудительно возвращая пользователя в контекст, который система считает "текущим".

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

Существующие сервера веб-приложений, поддерживающие наиболее популярные технологии (PHP,ASP,JSP) поддерживают понятие сессий, полностью принимая на себя управление (создание, отслеживание, удаление) контекстами.

Но в явном виде понятие сессии нужно не всегда - часто необходимый контекст вполне можно держать в куках и/или базе данных. Скажем, в системе разработки Communiware сессии в явном виде вообще нет.

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

Промежуточные варианты
Описанные выше фундаментальные различия породили много попыток решить их и с с помощью каких-то инструментальных средств программирования. Попытки эти шли по двум направлениям, решающим, вообще говоря, разные задачи.

1. Замена HTМL-интерфейсов специализированными агентами (ActiveX, Java-апплеты, в какой-то степени Flash и др.).

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

2. Разработка библиотек и серверов приложений, обеспечивающих "трансляцию" локальных интерфейсов через веб - как я их назвал в свое время, "веб - удлинители". Одной из таких систем был Байконур, с которым мне пришлось плотно поработать в конце 90-тых.

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

- интерфейсы и логику приложений все равно приходилось проектировать, учитывая ограничения ВЕБ-а

- автоматически сформированные экраны получаются некрасивыми, и не использующими преимуществ HTML-интерфейсов.

- издержки на поддержку множества запущенных полноценных приложений оказывались слишком велики, и все равно пришлось переходить на систему с единым сервером приложений и явным хранением контекстов.

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

Наша сила - обратная сторона нашей слабости
С моей точки зрения, основным преимуществом веб-интерфейсов является:

- возможность органичного сочетания активных и пассивных элементов на экране,

- разумное поведение изображения при изменении размеров и формы окна

- и отсутствие каких-либо ограничений на количество активных элементов.

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

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

Даже возможность перехода от упоминания объекта в любом контексте к описанию объекта, тривиальная для любого веб-приложения (ссылка), проблематична для широкомасштабной реализации в GUI. Не говоря уж о возможности встраивания форм редактирования объектов, которые генерируются в HTML так же легко, как и просто текст.

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

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

 
06.06.2005
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.