Главная              Рефераты - Разное

флягина Т. А. Проблемы разработки многооконных интерфейсов, квалификационная работа на степень бакалавра наук по направлению "Математика, прикладная математика": стр. 21, рис. 10, приложение 1, /библ. 3 назв - реферат

Федеральное агентство по образованию РФ

Государственное образовательное учреждение высшего профессионального образования

Уральский государственный университет им. А. М. Горького

Математико-механический факультет

Кафедра информатики и процессов управления

Проблемы разработки многооконных интерфейсов

"Допущен к защите"

___________________

"__"____________2008 г.

Квалификационная работа на

степень бакалавра наук

по направлению "Математика,

прикладная математика"

студента гр. Мт - 405

Флягина Т. А.

Научный руководитель

Авербух В. Л.

заведующий сектором, к.т.н.

Екатеринбург, 2008

РЕФЕРАТ

Флягина Т.А. ПРОБЛЕМЫ РАЗРАБОТКИ МНОГООКОННЫХ ИНТЕРФЕЙСОВ, квалификационная работа на степень бакалавра наук
по направлению "Математика, прикладная математика": стр.21, рис. 10, приложение 1, /библ. 3 назв.

Ключевые слова:

ИНТЕРФЕЙС, МНОГООКОННЫЕ СИСТЕМЫ, ПОРТЛЕТЫ, ВИДЖЕТЫ, ОКОННЫЙ МЕНЕДЖЕР.

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

Содержание

Содержание. 3

Введение. 4

Анализ оконных интерфейсов. 5

Без окон. 5

Полумеры.. 6

Мозаика. 6

Эластичные окна. 7

Многооконность. 7

Многооконные интерфейсы.. 9

Построение модели. 10

Автоматическое расположение окон. 10

Перемещение окон: 10

Изменение размера окна. 11

Работа с окнами в менеджере. 12

Добавление нового окна. 12

Быстрая вставка. 12

Практическая Реализация. 13

Менеджер работы с портлетами. 13

Что такое портлеты? Порталы? Портальный сервер?. 13

Менеджер работы с портлетами. 14

Алгоритм реализации. 14

Перемещение по горизонтали. 15

Перемещение по вертикали. 16

Отличия реализации от базовой модели. 17

Работа с активным окном. 18

Вставка новых окон. 18

Будущие и дополнения модели. 18

Дополнение базовой модели. 18

Виртуальный менеджер стола. 18

Метафора полки. 18

Менеджер портлетов. 18

Заключение. 20

Список литературы.. 21


Введение

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

Несмотря на все это, до сих пор нет интерфейса по настоящему работающему с многооконными интерфейсами.

Microsoft Windows по-прежнему проповедует "табовый" однооконный интерфейс, популярные оконные менеджеры для Linux его в той или иной степени копируют (возможность использовать многооконность, разумеется, есть, но она не особенно популярна). Немного отличается от мейнстрима Mac OS X, где по-прежнему используется классическая многооконность в стиле Xerox PARC. На удобство расположения окон влияет только привычка "Маков" не раскрывать окна на весь экран и подгонять их под размер документа, а не экрана. Этого, увы, недостаточно.

Анализ оконных интерфейсов

Окна были изобретены почти случайно. В семидесятые годы, когда в исследовательском центре Xerox PARC разрабатывали первый компьютер с графическим интерфейсом, качество растровых дисплеев оставляло желать лучшего. Разместить окна подобно перекрывающимся документам на столе предложил сам Алан Кей, руководивший этим проектом. "Это не казалось мне идеальным решением проблемы, но оно давало эффект значительного увеличения полезной площади на экране, так что я решил остановиться на нём," - вспоминал он потом в статье "Early History of Smalltalk".

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

Мог ли Кей предвидеть, что временное решение проблемы проживёт практически без изменений так долго? Технические ограничения, которые привели к появлению многооконного интерфейса, давно исчезли, но он успел стать настолько привычным, что об альтернативах почти никто не задумывается. А ведь они есть.

Без окон

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

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

Хотя в Windows поддерживаются перекрывающиеся окна, многие пользователи предпочитают этого не замечать - они всегда открывают приложения на полный экран. Для переключения между окнами в системе есть "панель задач", а Windows XP и Vista ещё и группируют окна одного приложения под одной вкладкой. Впрочем, объяснения здесь, вероятно, излишни, - Windows видели все.

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

Полумеры

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

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

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

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

Мозаика

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

Первая версия Windows, выпущенная более двадцати лет назад, обладала именно таким интерфейсом. На экране можно было открыть несколько неперекрывающихся окон, причём изменение размера одного из них приводило к изменению размера другого. Впрочем, куда успешнее этот подход применялся во многих программах с текстовым интерфейсом ещё во времена emacs. Старые пользователи PC помнят файловый менеджер Norton Commander, две панели которого тоже можно рассматривать как неперекрывающиеся окна.

Cпециальные программы, позволяющие разделять экран так, чтобы на нём легко умещались все открытые окна, называются мозаичными или тайловыми оконными менеджерами (от слова tile - плитка или черепица). Есть подобные разработки для Windows, но настоящее королевство подобных средств - UNIX-подобные операционные системы. В число наиболее распространённых тайловых оконных менеджеров входят Ion3, Ratpoison, WMII.

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

Эластичные окна

Концепция "эластичных окон", изобретённая десять лет назад в Мэрилендском университете, развивает идеи, лежащие в основе тайловых оконных менеджеров.

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

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

Многооконность

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

Microsoft Windows по-прежнему проповедует "табовый" однооконный интерфейс, популярные оконные менеджеры для Linux его в той или иной степени копируют (возможность использовать многооконность, разумеется, есть, но она не особенно популярна). Немного отличается от мейнстрима Mac OS X, где по-прежнему используется классическая многооконность в стиле Xerox PARC. На удобство расположения окон влияет только привычка "Маков" не раскрывать окна на весь экран и подгонять их под размер документа, а не экрана. Этого, увы, недостаточно.

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

Реализуй кто-нибудь хотя бы такую простую схему для работы с документами и окнами браузера, повседневное работа на компьютере могла бы стать намного удобнее. Но со времён Norton Commander ничего подобного не было и в ближайшем будущем, похоже, не предвидится.

Многооконные интерфейсы

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

Кроме работы пользователя есть масса задач, в которых просто необходимо работать с многооконностью.

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

Чтобы убедиться, что система работает нормально, необходимо провести комплексное тестирование всей системы одновременно.

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

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

Итак, многооконность может возникнуть:

- при тестировании бизнес - приложений (различные СВК)

- работа в распределенной ОС

- работа в WEB (большое количество вкладок)

Задачу, которую мы пытаемся решить, характеризуется:

- многооконностью;

- визуальным наблюдением (то есть нам достаточно рендеринга приложения, чтобы понять, что происходит);

- работа с одним окном, может влиять на другие окна;

- возможно одновременная работа с несколькими окнами (редактировать данные в одном, а копировать из другого)

- и тд

Построение модели

Когда люди манипулируют объектами и документами, то часто возвращаются к ним, ориентируюсь на свои воспоминания об их местоположении, а не восстанавливают в памяти фактические пути и названия.

Рассмотрим, например, рабочий стол Windows, Mac или Linux. Многие люди используют фон рабочего стола для размещения документов, ссылок на часто запускаемые приложения и других подобных вещей. Выясняется, что для поиска нужных объектов люди используют пространственную память, и это очень эффективных подход. Они придумывают собственные варианты группировок или вспоминают, что нужный документ “на самом верху, где-то рядом с вон тем значком”.

Естественно, можно найти эквиваленты и в реальном мире. Рабочие столы многих людей постоянно находятся в “художественном беспорядке” – для стороннего человека это просто куча барахла, в которой, однако, владелец стола может мгновенно найти нужную вещь. И боже упаси сделать уборку на таком столе!

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

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

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

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

Автоматическое расположение окон.

У пользователя полная свобода при работе с окном: он может менять размер окна или его местоположение. Каждое окно “живет” на панели.

Перемещение окон:

Перемещение окон, по сути означает, изменения порядка следования окон. Например, у нас были открыты последовательно окна А Б С. Теперь, мы хотим поменять порядок, что за А следовало С, то есть А С Б.

В реорганизации пространства, важна обратная связь – пользователь должен постоянно видеть как результат действий (в нашем случае перемещение и изменение размера) будет выглядеть целиком и когда с ним будет работать пользователь . Поэтому при перемещении, мы всегда видим как окно будет смотреться на новом месте (Рис 1 Вставка нового окна).

Рис 1 Вставка нового окна

Изменение размера окна.

Вернемся к простому примеру приложения с СВК. Тестировщику в данном случае достаточно наблюдать за логами работающей системы, при этом по рендерингу окна он может судить о поведении системы: штатный режим работы, или произошла ошибка.

В менеджере окон мы всегда видим актуальный рендеринг окна: что происходит сейчас в работающем приложении.

Поэтому наблюдая за несколькими окнами – мы можем изменить размеры для удобного визуального представления(Рис 2 Resize окна).

Рис 2 Resize окна

Работа с окнами в менеджере

У каждого окна есть 3 стандартных свойства: свернуть, развернуть, закрыть окно. Менеджер окон уметь распознавать эти состояния.

Свернуть окно. Тело окна “спрячется” и останется только заголовок окна. Чтобы вернуться к исходному виду необходимо развернуть окно.

Закрыть окно. При закрытии окна, она автоматически удаляться из представления в менеджере окон.

Развернуть окно: Это означает работать с окном не в менеджере окон, а как с отдельным окном. На самом деле, с окном можно работать и не выходя из менеджере окон, для этого окно нужно сделать Активным.

Активное окно. Чтобы работать с окном, не обязательно выходить в полно-функциональный режим (Развернуть окно). Если окно, позволяет, можно с ним работать непосредственно в менеджере.

Взаимодействие между окнами. Кроме функционально взаимодействия, еще есть и пространственное. То есть, когда окно меняет размер, это влияет на расположение других: они перемещаются влево/право исходя из уменьшения/увеличение по горизонтали текущего окна.

Добавление нового окна.

Если просто запустить нужно приложение, то его окно сразу попадет в менеджер окон, в конец списка, в новую строчку. Так как, именно там будет искать его пользователь.

Но на окно можно навешивать заранее ярлыки. В настройках менеджера окон указать комбинации клавиш на запуск окна (Например, <CTRL+SHIFT+KEY> и левая клавиша мыши).

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

И окно появиться.

Быстрая вставка.

Тащить большое окно через весь Бесконечный лист не удобно. Поэтому предусмотрена операция Быстрой вставки, она похожа на классическую операцию – вырезать/вставить. Для этого мы навешиваем временный ярлык на окно комбинацией клавиш (Например, вырезать -СTRL+SHIFT+T) и вставляем в нужное место. Аналогично работе с окнами-ярлыками.

Практическая Реализация

Применительно к WEB, данная модель может быть использована, как менеджер работы с портлетами.

Менеджер работы с портлетами.

Что такое портлеты? Порталы? Портальный сервер?

Сайт WebSphere Portal Server предоставляет рабочее определение IBM для портала: "Порталы обеспечивают безопасную, единую точку входа для взаимодействия с разнообразной информацией, бизнес-процессами и людьми, персонифицированную к потребностям пользователя и его обязанностям" . Есть хорошая аналогия между тем, что порталы добавляют к Web-приложениям, а оконный интерфейс (типа Microsoft Windows) добавляет к операционным системам (типа DOS). И то и другое обеспечивает совместимый и единообразный способ взаимодействия с приложениями.

Портлеты, согласно сайту WebSphere Portal, являются "видимыми активными компонентами, которые пользователи видят на страницах портала... В простейших терминах, портлет - это Java-сервлет, который работает внутри портала" . См. рис 1 с примером страницы портала с двумя видимыми компонентами. Каждый видимый компонент называется портлетом. В этом примере, один портлет позволяет пользователю отправиться по указанному URL; другой предоставляет пользователю текст с напоминанием.

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

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

Рис 3 Пример страницы портала с двумя портлетами

Менеджер работы с портлетами.

Собственно самое большее, что может делать с портлетами пользователь – это перетаскивать их по заранее заданной сетке (обычно с 1 степенью свободы и 2-мя колонками). Далее, мы будем относиться к портлету, как к обычному “окну”. Это можно сделать, так как портлеты помогают разделить сложные приложения на задачи: в целом, одна группа тесно связанных задач равняется одному портлету.

Поэтому, тут применима полностью модель, кроме некоторых дополнений.

Алгоритм реализации.

Основную роль играет перемещение объекта. Поэтому подробнее рассмотрим алгоритм для реализации именно этого свойство.

Объект А – этот тот объект который у нас является окном – портлетом. У него мы можем получить его parent – объект Б. У объекта Б соответственно, мы можем получить объект С. Объект С – это по сути панель, на которой живут портлеты (Рис 4 Архитектура панели).

Рис 4 Архитектура панели

Перемещение по горизонтали.

Перемещать объекты мы может по горизонтали и по вертикале. Сначала рассмотрим, как объекты переносятся по горизонтали.

По сути, перенос по горизонтали – это реорганизация последовательности объектов Б в панели С.

Предположим, что в данный момент, курсор мышки у нас находиться над текущим объектом А. Если он в правой половине, это означает, что мы хотим добавить объект после текущего, если в левой, соответственно, до. У текущего объекта А, получаем его parent – объект Б. Таким образом мы можем определить текущую панель С. Теперь нам просто нужно добавить новый объект до или после текущего объекта А(Рис 5 Перемещение по горизонтали).

Таким образом, нам не нужно знать в какой панели мы хотим размесить объект (в той же или в другой), нужно лишь получить объект панели (Рис 6 Перемещение по горизонтали).

Рис 5 Перемещение по горизонтали

Рис 6 Перемещение по горизонтали

Перемещение по вертикали.

Перемещение по вертикали отличается от перемещения по горизонтали тем, что мы:

1) должны добавить не просто объект, а создать панель с нашим объектом и разместить её в нужном месте;

2) parent у панели брать бессмысленно – у всех панелей он одинаковый.

Перемещение по вертикали по сути означает, что мы добавляем новую панель (новый ряд) с одним объектом. То есть, задача сводиться к тому, чтобы правильно определить место для вставки панели. Перемещение любой панели увеличивает или уменьшает контрольную сумму на 1 (Рис 7 Подсчет контр суммы).

Рис 7 Подсчет контр суммы

Подсчет контрольной суммы начинается с объекта, который хотим переместить(Рис 8 Добавление новой панели).

Рис 8 Добавление новой панели

На рисунке, красная линия – это перемещение курсора пользователя. Когда клавиша мыши будет отпущена, значение контрольной суммы станет равным n-1. Теперь нам надо получившийся порядок отобразить на текущий, чтобы знать после какого объекта добавлять новую панель. На рисунке (Рис 9 Определение уровня панели) показано, как пересчитывается порядок, d – номер панели в текущем порядке.

Рис 9 Определение уровня панели

Отличия реализации от базовой модели.

Так как мы работает в браузере, это накладывает некие ограничения в реализации модели, например при работе с активным окном и добавлением нового.

Работа с активным окном.

Когда пользователь работает с конкретным портлетом в режиме active (активное окно), текущий портлет раздвигается и становиться всплывающим окном.

Вставка новых окон.

Добавление новых “окон” осуществляется за счет добавления портретов на страницу.

Будущие и дополнения модели.

Дополнение базовой модели

Виртуальный менеджер стола.

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

Метафора полки.

Оставлю это здесь, чтобы не забыть заняться этим позже”.

Проспективная память – психологический феномен, который не получил внимания в дизайне интерфейсов.

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

Фактически каждый из нас применяет проспективную память и в жизни и при работе с компьютером: виртуальные липкие листочки; открытые окна на экране; примечания на документах: “Допиши меня”; закладки в браузере; документы на рабочем столе, а не в архиве; электронные сообщения, помеченные флагами и тд.

Почему бы не зарезервировать в менеджере окон специальную область – полку, на которую можно будет “складывать” приложения с которыми необходимо будет еще работать и тд.

В рамках модели, это будет не зависимая область, в которую можно просто переносить “копии” приложений. Сами приложения будут жить на панели прокрутки, в том порядке в котором их добавил пользователь.

Менеджер портлетов

Рассмотрим простую абстрактную модель приложения основанную на SOA – архитектуре (Рис 10 Простая абстрактная архитектура приложения). В такой системе, менеджер окон может выступать как прослойка между работой с сервисами (обрисовка окон) и работай пользователя (работа и компоновка окон). Таким образом мы можем рассматривать новый подход к созданию WEB-приложений и WEB-интерфейсов, похожий на стандартный подход в реализации корпоративных приложений.

Рис 10 Простая абстрактная архитектура приложения

Заключение

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

Интересной, с точки зрения разработки интерфейсов, получилась реализация модели для WEB-приложения. Интерфейс WEB-приложения может, в общем, полностью перенесен на перемещаемые панели.

Практическая реализация показала, что будет полезным реагировать на изменения размеров окна. Скажем, если мы отображаем табличку, при увеличении размера окна мы можем показывать новые колонки.

Список литературы

1) Дженифер Тидвелл, “Разработка пользовательских интерфейсов”, 2008

2) Статья “Куда Ведут Окна?”, Андрей Письменный, 2007