>>>Скачать презентацию в pdf<<<

При общении с коллегами частенько скатываешься на тему обсуждения проектов и заказчиков. Иногда все получается «как по маслу»: тебе доверяют и твои решения легко принимаются и командой, и заказчиком; а иногда приходится буквально сражаться за каждую идею. Почему? Тут можно много и долго говорить, а можно просто сказать, что в первом случае заказчики или проектная команда «созрели». Если они «созрели», то работается намного продуктивнее и интереснее.

Года полтора назад, прочитав вот эту и эту статьи Якоба Нильсена, я так определил для себя степени зрелости компании к внедрению юзабилити:

Уровень 0: О юзабилити только где-то слышали или вообще не слышали

Уровень 1: Использование базовых юзабилити-методов в тестировании (контрольные списки, простейшая инспекция, проверка доступности…)

Уровень 2: Уровень 1 + внедрение проектирования интерфейсов и их графического дизайна

Уровень 3: Уровень 2 + простейшее “партизанское” пользовательское тестирование, исследование пользователей

Уровень 4: Создание собственного отдела юзабилити, юзабилити-лаборатории.

Казалось бы, все просто. Добиться создания отдела юзабилити – и вы уже сразу на четвертом уровне. Если бы так. Ну вот, у вас, к примеру, есть юзабилити лаборатория, а пользоваться ею вы и ваши сотрудники умеете? (Если не было предварительного опыта, только где-то через год у вас начнет что-то получаться)

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

Эрик Шаффер пишет о том, что для того, чтобы специалист по юзабилити сумел работать на уровне, достаточном для независимой работы, требуется базовое образование и 3 – 5 лет работы на проектах соответствующего качества вместе с хорошим ментором. В наших реалиях эти сроки меньше, но объявления о поиске Usability Expert с опытом работы «от 1 года», по крайней мере, вызывают чувство недоумения.

Точно так же, как взрослеет отдельный специалист, взрослеет и отдел юзабилити целиком. Требуется время на освоение на должном уровне каждого нового метода, чтобы он заработал на 100%, на построение процесса внутри организации. Чем больший уровень развития, тем больше усилий и времени требуется для перехода на следующий. И срок тут идет скорее на годы, чем на месяцы. У Якоба Нильсена весь путь юзабилити взросления организации занимает порядка 20 лет.

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

Глава из книги «Shareware: профессиональная разработка и продвижение программ».
Станислав Жарков

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

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

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

Стандартные элементы интерфейса

Постарайтесь не использовать в своей программе нестандартные элементы интерфейса — например, командные кнопки не только с текстом, но и с рисунком, или комбинированные списки со сложной рамкой, которые в изобилии можно найти в oilline-коллекциях VCL и ActiveX-компонентов. Хотя бы потому, что именно так поступают профессиональные разработчики интерфейсов. “Чем стандартнее компоненты, тем лучше и профессиональнее вид” — не раз приходилось слышать от опытных авторов. Посудите сами: вы когда-нибудь видели в программе от Microsoft, Corel или Adobe элемент управления, сделанный начинающим программистом, выложенный в Интернете и сопровожденный припиской в файле readme.txt: “Это мой первый опыт в создании компонента, поэтому не пинайте слишком сильно!”

Замечание

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

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

Небольшая палитра инструментов

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

Одинаковое расстояние между элементами управления

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

TabOrder. “Правильный” порядок

TabOrder — это порядок, в котором экранный курсор перемещается по элементам управления в форме при нажатии клавиши Таb> на клавиатуре компьютера. На стадии разработки программы, при размещении элементов управления на форме, TabOrder эквивалентен тому порядку, в котором создаются эти элементы. Однако в процессе проектирования программы автор многократно меняет расположение элементов на форме, какие-то из них удаляет, добавляет новые компоненты. В результате почти всегда оказывается, что TabOrder не соответствует тому порядку, в котором визуально расположены элементы, и при нажатии клавиши Таb> курсор хаотично скачет по экрану вместо последовательного перемещения по компонентам.

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

Выбор шрифтов

Здесь все просто — автор не должен выбирать никаких шрифтов. Оставьте их такими, какими они определены по умолчанию, а лучше — укажите в свойстве Шрифт (Font) соответствующие глобальные переменные Windows: WindowText, MenuText и т. д. В этом случае смена пользователем стандартных шрифтов Windows по своему вкусу с помощью Панели управления отразится и на внешнем виде вашей программы. Таким образом, пользователь, запустив ваш продукт, окажется в знакомом ему окружении.

Еще один вопрос — предпочтительное начертание шрифтов. Современные системы программирования допускают указание для свойства Шрифт, помимо обычного (normal) начертания еще и полужирное (bold), курсивное (italic) и подчеркнутое (underlined), а также их сочетания. Многие авторы, обрадовавшись предоставленным возможностям, охотно ими пользуются, применяя различные комбинации шрифтовых начертании. На самом же деле в интерфейсах Windows-программ принято использовать всего два начертания: нормальное и полужирное (последнее — для выделения какой-либо важной информации, заголовков и т. п.). Применение курсива или подчеркивания, которое, к тому же, пользователь ошибочно может принять за гиперссылку — это дурной тон.

Масштабирование шрифтов

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

Выбор цветов

Здесь ситуация в точности такая же, как и со шрифтами: никакого выбора. При проектировании интерфейса нужно вообще забыть о свойстве Цвет (Color) элементов управления. Оставьте цвета стандартными, и пусть ваша программа выглядит так, как этого хочет ее пользователь, а не автор (хорошая идея — предусмотреть в программе возможность изменения цветовой гаммы различных частей интерфейса: многие пользователи любят настраивать цвета “под себя”, причем так, что другому человеку такое “сочетание” цветов может показаться совершенно неудобоваримым). И в этом, нужно сказать, авторам программ повезло: они лишены одной из самых главных забот дизайнеров и художников, какие же цвета выбрать для своего нового творения.

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

Альтернативное управление

Ваша программа должна одинаково хорошо управляться как с помощью мыши, так и клавиатуры. Не должно быть функций, которые можно выполнить только мышью (за исключением традиционно “мышиных” операций — например, рисования в графических редакторах). Наиболее популярные функции следует снабдить “горячими клавишами” для их быстрого вызова. При выборе комбинаций клавиш не забывайте о привычках и навыках пользователей: остановитесь на тех комбинациях, которые обычно используются в программах такого рода. Например, если вы разрабатываете файловый менеджер в стиле Проводника Windows, то лучше создавать комбинации, традиционные для Windows-программ (табл. 1); если же вы ориентируетесь на Norton Commander, то, например, для функции обновления списка файлов присвоите “горячую клавишу” +, а не Windows. Но, наверное, в такой ситуации идеальный, но, естественно, не самый легкий вариант — предусмотреть для функций программы две “схемы” горячих клавиш, чтобы удовлетворить потребности приверженцев обоих стилей работы с файлами.

Таблица 5.1. Стандартные комбинации клавиш в Windows Комбинация клавиш

Кирпичики интерфейса

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

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

• соответствия элемента управления выполняемой им задаче;
• от последовательности правил, по которым функционирует элемент управления.

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

Заголовок окна (формы)

Хотя в палитрах доступных программисту компонентов современных систем создания приложений отсутствует такой элемент управления, как заголовок окна, он определяется свойством Заголовок (Caption) объекта Форма (Form), ему нужно уделять не меньшее внимание, чем кнопкам, спискам и тому подобным элементам.

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

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

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

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

В новых версиях программных продуктов постепенно происходит отказ от традиционной схемы построения заголовков окоп. Например, Microsoft уже перевела на новый формат заголовка окна свои продукты — от простого “Блокнота” из состава Windows до программ пакета Office 2000.

Командные кнопки

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

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

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

Динамическое отключение и включение кнопки выглядит очень эффектно и производит впечатление высокого искусственного интеллекта программы (в большинстве случаев так и есть). Например, в диалоговых окнах кнопка ОК остается недоступной до тех нор, пока пользователь не введет необходимые данные, т. е. при каждом изменении информации происходит ее проверка. И вот здесь нужно быть очень осторожным. Дело в том, что пользователь при вводе сложных данных может не иметь информации о том, что именно он делает неправильно. “Серая” отключенная кнопка только говорит ему о том, что он что-то сделал не так, как нужно — например, ввел неверные или неполные данные, но вот в чем конкретно состоит проблема… И никто не может подсказать пользователю, что необходимо сделать, чтобы заветная кнопка наконец стала реагировать на нажатия мышью. Было бы гораздо лучше, если бы кнопка ОК была доступном, а после ее нажатия выдавалось бы сообщение об ошибке.

Лично мне приходилось не раз сталкиваться с описанной выше проблемой. Однажды я даже не смог зарегистрировать законно приобретенную копию sliareware-программы; кнопка Зарегистрировать все время оставалась отключенной, несмотря на ввод в текстовое окно регистрационного кода. И информацию о том, что именно я делаю неправильно, я смог получить, только написав письмо автору программы… Поэтому при проектировании интерфейса собственной программы, Actual Startup, я решил не поддаваться соблазну сделать диалоговые окна слишком “умными”. Кнопка ОК в окне создания нового “сервиса” становится доступной даже при вводе неправильных данных, зато после ее нажатия появляется окно с сообщением об ошибке и информацией о том, как ее исправить.

Текстовые подписи

Казалось бы, какие “подводные камни” могут быть при использовании одного из самых простых элементов управления — Label? Во-первых, не забудьте о масштабировании шрифтов: чтобы текстовая подпись автоматически подстраивала свои размеры согласно содержащемуся в ней тексту, проверьте, что свойство AutoSize имеет значение True. Во-вторых, также присвойте значение True свойству Transparent (если ваша среда разработки поддерживает его) — это приведет к тому, что фон подписи станет прозрачным, и гарантированно убережет вас от возникновения проблемы.

Вот такой он непростой, элемент Label: “обрезанный” текст и фон, не соответствующий фону основной формы, могут сильно испортить отношение пользователя ко всей программе.

Меню

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

В самых первых программах, предназначенных для работы на персональных компьютерах, меню представляло собой список операций, и для выбора какой-либо из них требовалось нажать на клавиатуре клавишу с цифрой, обозначающей порядковый номер соответствующей команды в меню. В программных продуктах для IBM PC середины 80-х годов, большинство из которых работало в текстовом режиме экрана (тот же Norton Commander), меню уже имело сложную структуру: команды были разбиты на группы, названия которых выводились в строке вверху экрана; по ниспадающим спискам команд можно было перемещаться нажатием клавиш со стрелками, а выбор делать при помощи клавиши . Во многих программах к управлению подключилась мышь.

С расцветом Windows и ростом популярности графического интерфейса меню заняло основное место среди средств управления компьютерными программами. Законодатель мод в области интерфейсов Windows-приложений — корпорация Microsoft — постоянно улучшала внешний вид и эргономику меню. В Windows 95 в меню были добавлены графические пиктограммы и возможность перемещения курсора мышью, а не только клавиатурой, как в Windows 3.1; в Windows 2000 появились “умные” меню, в которых первыми показывались наиболее часто вызываемые пользователем команды.

Но, тем не менее, всех этих заслуг меню в деле построения интерфейсов не производят на некоторых авторов программ никакого впечатления, и они — о ужас! — начинают считать, что без меню в программе вполне можно обойтись. Я как-то спросил одного из shareware-авторов, в главном окне программы которого присутствовала только кнопочная панель инструментов, а меню не было. “Да ну его… Я не знаю, чего туда помещать” — услышал я в ответ.

Вопрос “Что помещать в меню?” я рассмотрю чуть позже, а пока хотел бы обратить внимание на обязательность присутствия меню в главном окне программы. Это, если угодно, такое же правило хорошего тона, как и любое из эвристик Якоба Нильсена, о которых рассказывалось выше. Отказываясь от включения меню в проект своей программы, автор игнорирует опыт и навыки пользователей, заставляет их отказываться от стиля работы, к которому они привыкли. Особенно меня забавляет, когда авторы не делают в программе меню, но создают кнопочную панель инструментов: последняя появилась в интерфейсе программ для персональных компьютеров относительно недавно и, конечно, не может быть полноценной заменой меню. Хотя бы потому, что меню — это не просто список команд, это еще и многофункциональная “шпаргалка” по работе с программой, “шпаргалка”, которая всегда под рукой (как известно, читать справочные файлы пользователи не очень любят). Достаточно провести мышью по строке меню вверху экрана, и можно выяснить набор функций программы, комбинации “горячих клавиш” и даже — объяснение назначения кнопок на панели инструментов.

Замечание

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

Теперь — о том, что же можно помещать в меню. Некоторые авторы считают, что для простых программ меню вовсе не нужно, т. к. не стоит делать меню ради двух-трех пунктов. Но даже программа, которая ничего не делает, достойна меню как минимум из двух пунктов: Файл, где находится команда Выход и Справка, включающий подпункт О программе (ведь потенциальные пользователи должны знать, куда отправлять свои денежки, правда?).

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

И, конечно же, не стоит забывать о контекстных меню — меню, появляющихся при щелчке правой кнопкой мыши на каком-либо объекте и содержащими команды для работы с этим объектом. Разработка таких меню — дело, хотя технически очень простое, но при этом довольно кропотливое. Тем не менее, затраты времени и сил обязательно окупятся. Операционная система Windows 95 и ее последующие версии приучили пользователей к мысли, что при щелчке правой кнопкой мыши появляется контекстное меню. Щелчок правой кнопкой мыши стал уже настолько естественным действием, что программа, не “понимающая” его, напоминает человека, который не слышит, что ему говорят. Контекстное меню — одна из самых сильных привычек пользователей и навык, который имеют даже малоопытные новички. Нужно обязательно учитывать это при разработке интерфейсов собственных программ.

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

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

Списки

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

Во избежание возникновения подобных проблем нужно тщательно протестировать работу программы, чтобы выяснить, возможна ли ситуация, что в список будут выведены слишком длинные строки, чтобы уместиться в нем полностью. Если это не исключается, то можно предусмотреть средства, позволяющие все-таки полностью просмотреть “обрезанную” строку, например, при двойном щелчке мышью на интересующей пользователя строке выводить на экран небольшое окошко, где требуемый текст отображается полностью. Еще один хороший путь решения этой проблемы — заменить элемент Список (ListBox) более функциональным, скажем, ListView (в нем, например. Проводник Windows выводит список файлов). Задав определенным образом некоторые свойства ListView, можно добиться его полного внешнего сходства с традиционным списком, однако в отличие от последнего в окне ListView будет присутствовать горизонтальная линейка прокрутки.

Флажки и переключатели

Флажки (CheckBoxes) и переключатели (Option Buttons) используются для одной цели: для выбора из группы предложенных вариантов. Разница между ними, как вам, наверное, известно, состоит в том, что флажки используются для выбора одновременно нескольких вариантов из группы, а переключатели позволяют сделать выбор в пользу только одного варианта.

К сожалению, даже некоторые довольно авторитетные специалисты не придают большого значения этому различию между флажками и переключателями. В очередном номере Visual Basic Programmer’s Journal 101 Tech Tips for VB Developers, вышедшем в августе 1999 года, был опубликован небольшой кусок кода, который модифицировал функциональность группы флажков, позволяя им работать, как переключатели: с их помощью можно было выбрать только один вариант из предложенных. “Такое изменение может быть полезно, если вы хотите использовать флажки вместо переключателей”, — говорилось в публикации. Редактор сайта iarchitect.com с иронией предложил заменить вторую часть этой фразы на следующее: “…если вы хотите запутать ваших пользователей”. Ведь само появление на экране группы флажков сразу говорит пользователю о том, что сейчас ему можно будет сделать выбор нескольких вариантов, а не одного-единственного. Поэтому ни в коем случае не применяйте флажки для организации выбора одного варианта из группы.

Панели инструментов

Кнопочные панели инструментов (Toolbars) — излюбленный компонент многих разработчиков. С ним окно программы сразу приобретает более привлекательный, солидный и профессиональный вид. Любовь программистов к панелям инструментов настолько велика, что они, как я уже рассказывал чуть выше, даже отказываются в пользу них от святая святых пользовательского интерфейса — меню! Конечно, популярность компонента приводит к тому, что многие начинающие разработчики при включении панелей инструментов в свой проект сталкиваются с некоторыми “подводными камнями”.

Панель инструментов — довольно сложный и, так сказать, капризный компонент. Для его поддержки в Windows включена специальная библиотека — comctl32.dll. За историю развития операционных систем семейства Windows 9.x эта библиотека пережила несколько обновлений, что привело к тому, что в программах, созданных на более поздних версиях системы, с “новыми” версиями comctl32.dll, панель инструментов не может работать, если программа запущена под одной из предыдущих версий Windows. Опытные разработчики обязательно включают в справочные файлы своих программ информацию об этой проблеме. Они выкладывают на своих Web-сайтах новую версию comctl32,dll, чтобы пользователи не самых последних версий Windows могли нормально работать с программой. А вот если программист забывает об этом, то вскоре ему начинают приходить письма от пользователей с сообщениями о странной ошибке, в результате которой на кнопках панелей инструментов не видны пиктограммы.

Кстати, о пиктограммах. В интернет-конференциях, посвященных разработке программного обеспечения, часто задают вопрос: “Можно ли для панелей инструментов своих программ брать пиктограммы (иконки) из чужих продуктов?” Если кратко ответить на этот вопрос, то такое “заимствование” запрещено. Пиктограммы, как произведение изобразительного искусства (пусть и очень миниатюрное), охраняется авторским правом, и только автор (или лицо, которому он передал свои права) может использовать эти пиктограммы, а также разрешать или запрещать их использование.

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

А вот например, если вы решите позаимствовать для своей программы пиктограммы популярного менеджера закачек ReGet (http://www.reget.com), то вряд ли это окажется незамеченным. Эти пиктограммы были созданы специально для ReGet в одной из самых крупных студий дизайна в России — Студии Артемия Лебедева (http://www.design.ro), и разработчик ReGet -компания ReGet Software, конечно же, заинтересована в том, чтобы никто, кроме нее, не пользовался этими уникальными пиктограммами.

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

При проектировании панелей инструментов допускается, чтобы при нажатии и удерживании кнопки мыши на некоторых кнопках Панели инструментов вызывалось подменю с дополнительными командами. Если вы решили снабдить Панель инструментов в своей программе такими “сложными” кнопками, то позаботьтесь о том, чтобы соответствующим образом выделить их, иначе пользователь может и не догадаться, что это не обычная кнопка. Например, много нареканий вызывает интерфейс стратегической игры SimCity 2000: некоторые (но не все) кнопки на панели инструментов содержат подменю, появляющиеся, если нажать и не отпускать кнопку мыши на одной из них. Но пиктограммы на кнопках никак не указывают на эту их особенность. В результате у многих пользователей возникают проблемы при освоении интерфейса: признаться, в свое время я сам долго не мог понять, почему щелчок мышью по кнопке с изображением электростанции не позволяет мне добавить атомную электростанцию, хотя такая возможность была в предыдущей версии игры. Оказалось, что соответствующий тип электростанции, как и несколько других, вызывается из подменю, которое “спрятано” в кнопке.

А вот разработчики Adobe Photoshop были более последовательны: в нижнем правом углу каждой “сложной” кнопки в качестве индикации помещено изображение стрелки.

Тип границы кнопок на панелях инструментов — тоже не такой простой вопрос, как кажется. Традиционно кнопки на инструментальных панелях точно так же, как и обычные командные кнопки, имели объемную границу вокруг них. Сложившийся порядок нарушил выход версии 3.0 браузера Microsoft Internet Explorer, Кнопки на панели инструментов этой программы имели “плоский” вид: граница появлялась на них лишь после того, как пользователь наводил на кнопку курсор мыши. Оригинальную, хотя и нс бесспорную идею охотно подхватили все разработчики, и сегодня практически все программы имеют “плоскую” панель инструментов. Лично я разделяю мнение, что “плоская” панель инструментов выглядит очень необычно и интересно, однако есть пользователи, которым больше по душе традиционное оформление панели инструментов, когда кнопки выглядят именно так, как должны выглядеть кнопки. И те разработчики программ, которые стараются не упускать из виду даже самые незначительные мелочи, предусматривают в своих продуктах возможность смены пользователем вида панели “обычный”/”плоский”, тем более что технически реализовать такую функцию в программе очень просто — нужно менять значение всего одного свойства.

Вкладки

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

Да, вкладки позволяют упорядочить большие объемы данных, однако это полезное свойство вкладок сходит на нет, если число самих вкладок становится слишком большим. Здесь явно наблюдается противоречие с правилом кошелька Миллера (см. разд. “Другие принципы построения интерфейсов” данной главы), определяющим, что человек может удерживать в своей кратковременной памяти семь плюс-минус две сущности. Поэтому в нескольких рядах вкладок, которые уже перестают умещаться в рамках диалогового окна, очень легко запутаться. Даже тот десяток вкладок, которые находятся в окне Параметры Microsoft Word, вызывает многочисленные нарекания со стороны пользователей. Действительно, мало кому не приходилось беспорядочно щелкать по вкладкам окна настроек Microsoft Word, чтобы отыскать нужную опцию.

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

Если посмотреть, как эта проблема решается в известных shareware-программах, то можно заметить, что их авторы стремятся уменьшить число вкладок в диалоговых окнах за счет разделения всех вкладок в новые группы, где число вкладок относительно невелико. Например, в главном меню популярного почтового клиента The Bat! (http://www.ritlabs.com) есть отдельный пункт — Свойства, а в нем — несколько подпунктов, вызывающих соответствующие диалоговые окна: Редактор писем. Быстрые шаблоны. Подключение и администрирование и т. п. В некоторых из них вообще отсутствуют вкладки, а некоторые обошлись всего лишь двумя-тремя вкладками. В не менее популярном текстовом редакторе UltraEdit аналогичным образом разнесены окна настройки самого редактора и вспомогательных утилит. В уже много раз упоминавшейся программе Chameleon Clock, в окне Свойства создано три группы опций: Настройки, Действия и Виды (переключение между ними происходит при помощи панели в стиле Microsoft Outlook), в которых находятся по четыре- пять вкладок (а в опции Виды их вообще нет).

Всплывающие подсказки

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

Нужно помнить, что всплывающие подсказки — спутник далеко не любого компонента на форме приложения. Традиционно они используются для “озвучивания” назначения только кнопок на панелях инструментов, секций на строке состояния и…, пожалуй, все. Есть некоторые случаи использования всплывающих подсказок для других компонентов (например, вертикальная линейка прокрутки в Microsoft Word или меню Пуск в Windows 2000), но это скорее исключение, чем правило.

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

Осторожно: скины

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

Человек всегда стремится как-то выделиться, придать себе и своим вещам индивидуальность. Многие люди стараются так украсить собственный дом, автомобиль, рабочее место, чтобы они отличались от других. То же самое наблюдается с компьютерами: пользователи устанавливают в качестве “обоев” Рабочего стола Windows понравившиеся картинки, перенастраивают цветовую и звуковую схемы. Введение возможности изменить вид программы по своему вкусу — закономерное развитие компьютерных интерфейсов, еще один шаг к удовлетворению желания пользователей настраивать все “под себя” и индивидуализировать себя и свое окружение.

Хрестоматийный пример программы, использующей скины, — это мультимедийный плейер WinAmp (http://www.winamp.com). Именно после ее выхода слово “скины” стало очень модным. Огромной популярностью стали пользоваться программы, как и WinAmp, позволявшие менять “кожу”, online-коллекции скинов (например, сайт http://www.skinz.org). Слово “скины” буквально завораживало пользователей, и они торопились скачать и опробовать любой программный продукт, в описании которого оно встречалось. Естественно, сам WinAmp тоже не остался без внимания, заполучив огромную аудиторию пользователей со всего мира, и его часто приводят как пример удачного маркетингового хода.

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

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

Некоторые программисты не обращают на эти доводы никакого внимания:

“Подумаешь, несовместимость форматов, ну и пусть, что скинов мало — главное, они, скины, ЕСТЬ!” Но давайте-ка немного порассуждаем. Если каждая программа использует собственный формат скинов, значит, существует вероятность, что в разных программах скины будут также разные (на самом деле именно так и есть). Кроме того, раз для каждой программы существует всего лишь по паре десятков “шкур”, то пользователь “точно не сможет выбрать из них ту, которая устраивает его на сто процентов. И теперь представьте картину: каждая программа на компьютере пользователя имеет разный вид, да к тому же и не полностью устраивающий хозяина системы, Кстати, вряд ли пользователи будут самостоятельно рисовать скины к вашей программе: это не такое уж простое занятие, а в ситуации, когда скины требуются сразу для нескольких программ на компьютере, это дело становится и вовсе бесперспективным

Гораздо более выигрышный вариант — пойти в фарватере лидера (прием, который действенен не только в области программирования вообще и скинов в частности). Кандидатура на эту роль только одна: WinAmp. Посудите сами:

• WinAmp — самая популярная программа, которая поддерживает скины. Благодаря действительно хорошим функциональным возможностям и бесплатности, она чаще всего используется как плейер звуковых файлов;
• к WinAmp уже нарисовано огромное количество скинов — более сорока трех тысяч (!) на август 2001 года; ·
  некоторые программы независимых разработчиков уже поддерживают скины WinAmp.

Таким образом, сделав свой продукт совместимым со “шкурам” WinAmp, вы одним выстрелом убиваете не двух, а трех зайцев, получая:

• десятки тысяч готовых скинов, доступных пользователям;
• огромную потенциальную аудиторию, значительная часть которой вполне может из потенциальной стать реальной: многие пользователи захотят заполучить, например, калькулятор или записную книжку, которые выглядят так же, как и их любимый WinAmp;
• возможность эффективно рекламировать свою программу: наличие в описании программы слов “поддержка скинов WinAmp” дает неплохой отклик со стороны пользователей на поисковых системах и в online-архивах программного обеспечения.

Если вы захотите встроить в свою программу поддержку скинов, то сначала хорошенько подумайте: а действительно ли “шкуры” так необходимы вашему продукту?

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

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

Но, уж если вы все-таки встроили в свою программу поддержку скинов, позаботьтесь о том, чтобы пользователь мог ее отключить, вернувшись к традиционному виду. Стандартное оформление Windows-приложений — это тоже своеобразный скин, и у него есть немало приверженцев.

>>> Источник: “Мастерская Dr.dimdim” <<<

Глава из книги «Shareware: профессиональная разработка и продвижение программ».
Станислав Жарков

Золотое сечение

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

В математике пропорцией называют равенство двух отношений: a : b = с: d.

Отрезок прямой АВ можно разделить точкой С на две части следующими способами:

• на две равные части АВ : АС = АВ : ВС,
• на две неравные части в любом отношении (такие части пропорции не образуют);
• таким образом, когда АВ: ВС = ВС: АС.

Последнее и есть золотое деление или деление отрезка в крайнем и среднем отношении.

Золотое сечение — это такое пропорциональное деление отрезка на неравные части, при котором весь отрезок так относится к большей части, как сама большая часть относится к меньшей; или другими словами, меньший отрезок так относится к большему, как больший ко всему.

а : b = b : с или с : b = b : а.

Отрезки золотой пропорции выражаются бесконечной иррациональной дробью 0,618…, если с принять за единицу, а = 0,382. Отношение же отрезков а и b составляет 1,618.

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

Есть и золотой треугольник (равнобедренный треугольник, у которого отношение длины боковой стороны к длине основания равняется 1,618), и золотой кубоид (прямоугольный параллелепипед с ребрами, имеющими длины 1,618, 1 и 0,618).

Золотое сечение не является искусственным явлением. Оно очень широко распространено в природе: золотое сечение можно найти в пропорциях тел многих растений и животных, а также морских раковин и птичьих яиц. Но наиболее впечатляющий пример “применения” природой принципа золотого сечения — человеческое тело. Оно целиком и его части (лицо, руки, кисти рук и т. п.) насквозь пронизаны пропорцией 1,618.

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

С развитием дизайна и технической эстетики действие закона золотою сечения распространилось на конструирование машин, мебели и т. д. Проектирование компьютерных интерфейсов — не исключение. Формы диалоговых окон и элементов управления, стороны которых относятся как 1,618, очень привлекательны для пользователей. Например, очень много восторгов у пользователей программы Chameleon Clock (http://www.softshape.com) вызывает такая, казалось бы, обыденная вещь, как вид диалогового окна Свойства. А все потому, что при его проектировании использовался именно принцип золотого сечения.

Кошелек Миллера

Этот принцип назван так в честь ученого-психолога Г. А. Миллера, который исследовал кратковременную память, проверяя выводы, сделанные ранее его коллегой, Г. Эббингаузом. Эббингауз пытался выяснить, сколько информации может запомнить человек без каких-либо специальных мнемонических приемов. Оказалось, что емкость памяти ограничена семью цифрами, семью буквами или названиями семи предметов. Это “магическое число” семь, служащее своего рода меркой памяти, и было проверено Миллером, который показал, что память действительно в среднем не может хранить более семи элементов; в зависимости от сложности элементов это число может колебаться в пределах от пяти до девяти.

Если необходимо в течение короткого времени сохранить информацию, включающую больше семи элементов, мозг почти бессознательно группирует эту информацию таким образом, чтобы число запоминаемых элементов не превышало предельно допустимого. Например, номер банковского счета 30 637 402 710, состоящий из одиннадцати элементов, будет, скорее всего, запоминаться как 30 63 740 27 10, т. е. как пять числовых элементов, или восемь слов (тридцать, шестьдесят, три, семьсот, сорок, двадцать, семь, десять).

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

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

Принцип группировки

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

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

Бритва Оккама или KISS

Философский принцип, носящий название “Бритва Оккама”, гласит: “Не множить сущности без надобности”. Или, как говорят американцы, KISS (“Keep It Simple, Stupid” — “He усложняй, болван”).

На языке интерфейсов это означает, что:

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

Простым на первый взгляд требованиям из этого списка на самом деле не так уж легко следовать. Для проектирования сложного по своим функциям и простого для понимания интерфейса требуется немалые опыт, знания и особое чутье. Как пишет Лу Гринзоу: “Если и есть в мире что-то такое, что почти все программисты постоянно повторяют наизусть, как мантры, но при этом откровенно игнорируют, так это — принцип KISS’”.

Принцип KISS перекликается с несколькими из эвристических правил Якоба Нильсена — “Эстетичный и минималистический дизайн”, “Равенство между системой и реальным миром”, “Понимание лучше, чем запоминание”. KISS более универсален и применяется практически во всех сферах человеческой деятельности, в том числе и в области, очень близкой к теме книги—в программировании.

Видимость отражает полезность

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

Этот вопрос уже немного затрагивался при разговоре о принципе Якоба Нильсена “Эстетичный и минималистический дизайн”, правда, в привязке к отражению полезности.

Отличие принципа “Видимость отражает полезность” как раз и состоит в том, что интерфейс программы должен быть построен вокруг объектов, с которыми манипулирует пользователь, и отражать состояние текущего объекта. Реализацию этого принципа вы видите каждый раз, когда пользуетесь компьютером: контекстные панели инструментов в программах пакета Microsoft Office, которые меняются в зависимости от того, с какой частью программы (редактором, предварительным просмотром, рисованием и т. п.) и данный момент работает пользователь. Еще один пример — уже упоминавшееся меню Пуск в Windows ME и Windows 2000: по умолчанию в них видимы наиболее часто используемые, т. е. полезные для пользователя, пункты.

Умное заимствование

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

Заимствование чужих интерфейсных находок не является чем-то зазорным. Программы, лидирующие па рынке, являются неистощимым источником вдохновения для разработчиков более мелких программ, поразительно напоминающих легендарный Norton Commander: FAR, Volcov Commander, DOS Navigator, DISCo Commander

>>> Источник: “Мастерская Dr.dimdim” <<<

Когда говорят о научных основах проектирования пользовательских интерфейсов, в первую очередь упоминают термин HCI. HCI — это аббревиатура английского Human-Computer Interaction, что переводится как “взаимодействие человека и компьютера”. На Западе HCI — это целая профессия, ей обучают в университетах, выдавая дипломы “Специалист по HCI”. Издается много журналов по этой теме, существует большое количество Web-сайтов. В России, к сожалению, эта наука не пользуется особой популярностью например, у нас настоящих специалистов по HCI можно буквально пересчитать по пальцам одной руки.

Как легко догадаться по названию, составными частями HCI являются:

• человек (пользователь)
• компьютер
• их взаимодействие.

Пользовательский интерфейс (англ. user interface, UI) является своеобразным коммуникационным каналом, по которому осуществляется взаимодействие пользователя и компьютера.

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

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

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

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

Если говорить о самых общих принципах проектирования пользовательских интерфейсов, то можно назвать три основных положения:

1. Программа должна помогать выполнить задачу, а не становиться этой задачей.

2. При работе с программой пользователь не должен ощущать себя дураком.

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

Довольно эмоциональные формулировки, но, тем не менее, поразительно верные.

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

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

Во-первых, традиционным слегка высокомерным отношением программистов к простым пользователям. Это еще можно было понять в восьмидесятых и начале девяностых годов XX века, когда обычные персональные компьютеры не имели доступных широкой аудитории программных и аппаратных средств для построения привлекательных графических интерфейсов и работы с ними. Самой распространенной операционной системой в то время была MS DOS, основанная на интерфейсе командной строки. Поэтому эффективно работать с персональным компьютером могли люди только с довольно серьезной подготовкой. Кроме того, парк “персоналок” был относительно невелик даже в США, не говоря уже об остальных странах, и, как следствие, число пользователей компьютеров было небольшим.

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

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

И, наконец, третья причина во многом обусловлена поведением самих пользователей. Часто при возникновении малейших затруднений при работе с программой пользователь тут же обращается в службу технической поддержки, не удосужившись даже взглянуть на справочную систему продукта, посмотреть секцию “Ответы на частые вопросы” на Web-сайте программы или даже просто чуть-чуть подумать! Отчасти тут вина самих авторов программ. Как говорят опытные разработчики пользовательских интерфейсов: “Если уже на этапе знакомства с программой пользователь вынужден обращаться к справочной системе, над интерфейсом нужно серьезно работать”. Поэтому, чтобы соблюсти второй из общих принципов построения интерфейсов и не давать пользователю повода почувствовать, будто его принимают за идиота, не нужно давать разрабатываемой программе слишком большие полномочия и право указывать пользователю, что именно ему делать. Некоторые программисты не знают или не желают осознавать этого и загоняют пользователей своих программных продуктов в тесные рамки, навязывая определенный стиль работы.

Один из примеров такого неправильного отношения к пользователю является отказ программы выполнить вполне естественную с точки зрения пользователя программных продуктов такого рода операцию и вывод диалогового окна, требующего выполнить какую-то другую последовательность действий. Этим “прославился”, например, известный текстовый редактор “Блокнот” из состава Windows 95. Если пользователь открывал эту программу и решал перед началом набора текста дать создаваемому “Блокнотом” по умолчанию файлу “Untitled” какое-нибудь имя, выбрав из меню команду Сохранить как, редактор отказывался сделать это, показывая сообщение: “Вы не ввели какой-либо текст, чтобы его можно было сохранить. Наберите какой-нибудь текст, а затем попытайтесь [сохранить его] снова”. Этим создатели “Блокнота” не только отвергли стиль работы очень многих пользователей (перед началом набора текста дать имя файла), но сбили с толку и тех, кто был знаком с “Блокнотом” по предыдущим версиям Windows. Например, в шестнадцатиразрядной Windows 3.1 “Блокнот” позволял сохранять пустые файлы безо всяких проблем. Опытные пользователи, знакомые с принципами работы операционной системы, тоже были в недоумении: если из контекстного меню Проводника Windows в меню Создать выбрать пункт Текстовый документ, то получившийся файл длиной 0 байт открывается “Блокнотом” без каких-либо затруднений. К счастью, в последующих версиях Windows “Блокнот” стал более дружественен к пользователю.

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

И, наконец, третий принцип — “Программа должна работать так, чтобы пользователь не считал компьютер дураком”.

Несмотря на стремительное развитие информационных технологий, многие компьютерные программы все еще имеют примитивный искусственный интеллект. Они прерывают работу пользователя глупыми вопросами и выводят на экран бессмысленные сообщения, повергая его в недоумение в самых простых ситуациях. В результате многие люди, работающие с компьютерами, раздраженно восклицают: “Как мне надоела эта тупая машина!”

Примечание

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

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

А этот пример особенно часто приводится в качестве иллюстрации к рассказу о “тупых” интерфейсах. Утилита преобразования текстовых файлов, включенная в Microsoft Word, способна распознать формат открываемого файла. Но, тем не менее, она просит пользователя подтвердить, что структура файла была определена правильно. Во многих случаях (например, когда человек открывает файл, созданный не им, или просто при недостатке знаний) он не может указать, каков формат файла на самом деле. Но, т. к. его все-таки просят сделать выбор, он начинает колебаться, выбирать из списка другие форматы, что приводит к некорректным результатам.

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

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

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

>>> Источник: “Мастерская Dr.dimdim” <<<

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

Разработка эффективных форм

Формы – это строительные блоки интерфейса пользователя. Хороший дизайн форм включает нечто большее, чем просто добавление элементов управления и программирование процедур обработки событии. Чтобы создать хорошо спроектированную форму, вы должны уяснить ее назначение, способ и время использования, а также ее связи с другими элементами программы. Кроме того в приложении может находиться несколько форм, каждая из которых будет отображаться по мере необходимости. Одни пользователи широко используют многозадачность Windows, другие предпочитают работать только с одним приложением. Необходимо помнить об этом во время разработки интерфейса пользователя (UI) Вы должны максимально реализовать все возможности Windows, чтобы пользователи с любыми навыками работы могли эффективно применять созданное вами приложение.

Проектирование форм ввода данных

Особый вид форм – формы, предназначенные для ввода данных. Они позволяют пользователь в нужном ему темпе, не оглядываясь на программиста. Общий смысл и основное правы: если пользователь собирается ввести в базу данных 10000 записей, вероятно, он не подтверждать ввод каждой записи. В форме ввода данных необходимо максимально использовать свободное пространство, поскольку открытие и закрытие дополнительных форм существенно замедляет работу. При разработке форм ввода данных основное внимание следует уделить скорости их работы. Чтобы максимально ускорить процесс ввода данных, следуйте приведенным ниже основным правилам.

• Всегда назначайте клавиатурные эквиваленты команд; не требуйте обязательного использования мыши. (Кстати, этот совет хорош для всех форм программы, а не только для форм ввода данных.)
• Расположение элементов должно быть согласовано с задачами пользователя. Другими ело вами, не заставляйте пользователя перепрыгивать из раздела в раздел; при вводе информации это совсем не обязательно.
• Не заставляйте пользователя выполнять лишнюю работу. Другими словами, если информация, содержащаяся в полях со 2-го по 10-е, необходима только, когда первое поле имеет определенное значение, не нужно заставлять пользователя заполнять все поля подряд. же время, не ставьте работу формы в зависимость от содержимого отдельных полей. В противном случае это может существенно замедлить работу пользователя.
• Используйте заметную, но ненавязчивую обратную связь с пользователем. Хороший пример – работа редактора программного кода Visual Basic, который проверяет правильной написания переменных и констант.
• Если возможно, выполняйте добавление и редактирование записей в одной и той же форме, тогда пользователю не придется осваивать несколько методов доступа к одним и тем желанным.

Работа с несколькими формами

Если интерфейс пользователя должен содержать несколько форм, вам предстоит принять самое важное решение: какой использовать вид интерфейса- однодокументный (SDI) или многодокументный (MDI).

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

Эффективные меню

Еще одна важная часть разработки форм – создание содержательных и эффективных меню. Приведем некоторые важные рекомендации:

• Следуйте стандартным соглашениям о расположении пунктов меню принятым в Windows File, Edit, View, и т.д.
• Группируйте пункты меню в логическом порядке и по содержанию.
• Для группировки пунктов в раскрывающихся меню используйте разделительные линии
• Избегайте избыточных меню.
• Избегайте пунктов меню верхнего уровня, не содержащих раскрывающихся меню
• Не забывайте использовать символ троеточия для обозначения пунктов меню, активизирующих диалоговые окна.
• Обязательно используйте клавиатурные эквиваленты команд и “горячие” клавиши.
• Помещайте на панель инструментов часто используемые команды меню.

Ощущение скорости

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

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

Информируйте пользователя о ходе процесса

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

Выводы по проектированию пользовательского интерфейса

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

>>> Источник: “Мастерская Dr.dimdim” <<<

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

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

Основные задачи средств разработки графического интерфейса

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

Производительность

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

Защита инвестиций (минимизация доработок)

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

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

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

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

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

Простота переноса на другие платформы означает, по крайней мере то, что графические структуры, созданные на одной платформе, могут использоваться и на платформе другого поставщика без модификации. Более глубокий смысл этого требования предполагает то, что объекты графического управления, такие как “widgets” среды Motiff или “controls” Microsoft автоматически приобретают правильную форму в зависимости от среды, в которой компонуется и выполняется прикладная программа.

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

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

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

Возможность многократного использования элементов экранных картинок – это аспект как производительности, так и защиты инвестиций.

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

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

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

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

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

Анализ графической “глубины” проектируемого приложения

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

В общем, полезно анализировать разрабатываемое приложение с точки зрения его графической “глубины”. Определение графической глубины требует оценки приложения в трёх “измерениях”, которая может начинаться с формулирования следующих трёх вопросов:

• насколько “графическим” является приложение?
• насколько динамической или удовлетворяющей требованиям реального времени должна быть графическая часть?
• сколько переходов состояний при этом используется и насколько они сложны?

Первый из этих трех вопросов отражает тот факт, что термин “графический пользовательский интерфейс” (GUI – graphical user interface) до сих пор используется на рынке для обозначения интерфейса, который хотя и является графическим по отношению к интерфейсам на основе символьных терминалов, но в действительности не является “истинно” графическим, так как использует в основном текстовые объекты – меню и диалоги – а не изображения реальных управляемых объектов.

Большинство имеющихся на рынке средств может классифицироваться как GUI-конструкторы. Это означает, что они предназначены для создания интерфейсных GUI-средств (меню, диалогов, окон просмотра и т.д.) в конкретной среде, в основном в Х Windows/Motif или Windows NT/95. Говоря в целом, эти средства предоставляют редакторы, которые могут легко создавать объекты среды Motif (widgets) или объекты на базе фундаментальных классов Microsoft (Microsoft Foundation Class-based Controls (ниже MFC-объектов), но не предоставляют общих графических средств для создания представлений реальных объектов управляемого процесса.

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

Зачастую они с запозданием понимают, что такой конструктор предоставляет им только widget-объекты в области рисования или документы в формате Windows, которые должны быть обеспечены “истинно” графическими средствами из других источников, и что заполнение этих пустых окон, даже если на них приходится 20% всего интерфейса, может занимать до 80% времени разработки.

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

Недавно для решения этой проблемы в целом ряде GUI-конструкторов были добавлены общие средства рисования. В некоторых случаях, для отличия от GUI-средств, не содержащих подобной возможности, их обозначают как VGUI-средства (VGUI – very graphical user interface – настоящий графический пользовательский интерфейс). Это свидетельствует о важности оценки планируемого интерфейса с точки зрения первого “измерения”, меняющегося в диапазоне от “ненастоящий графический” (объекты управления только на базе текстов), до “настоящий графический” (требующий много “истинно” графических изображений реальных элементов).

Следующее измерение при анализе требований к графическому интерфейсу – это степень “динамичности” его графики. Лишь в редких случаях для прикладной АСУТП достаточно простого сочетания GUI-объектов и статической графики.

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

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

Вопрос, всегда болезненный для разработчиков, что предпочесть – функциональность или простоту использования, обсуждается в конце статьи.

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

Концепция переходов состояний используется во многих методиках объектно-ориентированного анализа и проектирования как средство моделирования динамического поведения реального процесса. Типичное определение этого понятия выглядит следующим образом:

“Этот жизненный цикл [то есть объект в реальном процессе - комм. К. У.] формализуется через модель состояний: набор состояний и событий. Состояние объекта представляет ситуацию или условие, во время которых применимы определенные физические законы, правила или тактики поведения. Событие представляет некоторое происшествие, которое вызывает переход объекта из одного состояния в другое.” (из книги Шлера и Меллора “Жизненные циклы объектов, моделирование мира через состояния.” – Shiaer and Mellor, Object Lifecycles, Modelling the World in States, Yourdon Press).

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

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

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

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

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

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

Необходимо ли отказываться от функциональности ради простоты использования?

Если, как это часто бывает в приложениях АСУТП, разработчик понимает, что разрабатываемый интерфейс должен быть “глубоким” (то есть настоящим графическим, очень динамичным или с большим количеством переходов), то возникает вопрос, следует ли принести простоту использования, в смысле легкости разработки, в жертву требуемой функциональности.

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

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

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

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

И снова полезно исследовать простоту использования с точки зрения трех обсуждавшихся выше “измерений”.

Степень использования графики

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

• полный набор графических примитивов, включая дуги, секторы и сплайны;
• возможность быстрого сохранения и повторного использования графического элемента;
• возможность ограничивать повторное использование графического элемента глобальными или локальными рамками, так что модификации первоначального элемента распространялись бы либо на все экранные схемы, либо только на некоторые;
• возможность создания “палеток” повторно используемых элементов;
• конфигурируемая таблица цветов;
• разнообразные позиционирующие средства, такие как переменное разрешение сетки х-у, притягивание к решетке, выравнивание текста, позиционирование групп и т.п.;
• ряд опций по выбору элемента, как например выбор мышкой, резиновой нитью, по имени, по цвету, рамкой х-у, по типу динамического поведения и другим параметрам;
• поддержка иерархически упорядоченных элементов, с возможностью модификации отдельных элементов после их включения в иерархию;
• возможность создания средств управления (кнопки, меню, диалоги), которые получают подходящий GUI-тип после вызова соответствующей библиотеки (например Motif, фундаментальные классы Microsoft) на этапе компоновки;
• возможность одновременно редактировать в более чем одном Х-окне или “документе” Microsoft;
• возможность создавать упрощенные, ориентированные на приложение графические редакторы для использования оператором.

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

Динамичность

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

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

Переходы состояний

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

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

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

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

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

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

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

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

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

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

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

Источник: Real-Time Magazin, 4/95

]]> https://guimachine.ru/?feed=rss2&p=943 0 https://guimachine.ru/?p=937 https://guimachine.ru/?p=937#comments Wed, 02 Oct 2013 11:25:49 +0000 admin http://savvinov/?p=937 Подробнее]]> Клещев А.С., Грибова В.В. 25.03.2001

Интерфейс имеет важное значение для любой программной системы и является неотъемлемой ее составляющей, ориентированной, прежде всего, на конечного пользователя. Именно через интерфейс пользователь судит о прикладной программе в целом; более того, часто решение об использовании прикладной программы пользователь принимает по тому, насколько ему удобен и понятен пользовательский интерфейс. Вместе с тем, трудоемкость проектирования и разработки интерфейса достаточно велика. По оценкам специалистов в среднем она составляет более половины времени реализации проекта [1]. Актуальным является снижение затрат на разработку и сопровождение программных систем или разработка эффективного программного инструментария, где под эффективностью понимается простота разработки, легкость сопровождения и удобство работы с программой [2].

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

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

В литературе не существует единой общепринятой классификации средств для разработки пользовательского интерфейса. Так, в [3] программное обеспечение для разработки пользовательского интерфейса разделяется на две основные группы – инструментарий для разработки пользовательского интерфейса (toolkits) и высокоуровневые средства разработки интерфейса (higher-level development tools). Инструментарий для разработки пользовательского интерфейса, как правило, включает в себя библиотеку примитивов компонентов интерфейса (меню, кнопки, полосы прокрутки и др.) и предназначен для использования программистами. Высокоуровневые средства разработки интерфейса могут быть использованы непрограммистами и снабжены языком, который позволяет специфицировать функции ввода-вывода, а также определять, используя технику непосредственного манипулирования, интерфейсные элементы. К таким средствам авторы относят построители диалога (interface builders) и СУПИ – системы управления пользовательским интерфейсом (User Interface Management Systems – UIMS). Помимо СУПИ, некоторые авторы используют такие термины, как User Interface Development Systems (UIDS) – системы разработки пользовательского интерфейса, User Interface Design Environment (UIDE) – среда разработки пользовательского интерфейса и др.

В [4] инструментарий для разработки интерфейса разделен на три группы, которые определяются следующим образом. В первую группу входит инструментарий для поддержки создания интерфейса написанием кода – UIMS и Toolkits; во вторую – интерактивные инструментальные средства, позволяющие сконструировать интерфейс из “заготовок” (кнопок, меню, полос прокрутки и т.д.), – Interface Builders; третий тип основан на создании интерфейса путем связывания отдельно созданных его компонент – Component Architectures.

Как замечено в [2], терминология данного направления окончательно не сформировалась и в настоящее время также является предметом исследования. Однако в большинстве работ для ссылки на специализированные средства для разработки интерфейса приводится термин СУПИ, который и будет использоваться в данной работе.

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

Можно выделить несколько основных способов спецификации интерфейса [2].

1. Языковой, когда применяются специальные языки для задания синтаксиса интерфейса (декларативные, объектно-ориентированные, языки событий и др.).

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

3. Спецификация интерфейса, основанная на объектно-ориентированном подходе, связана с принципом, называемым непосредственное манипулирование. Основное его свойство – взаимодействие пользователя с индивидуальными объектами, а не со всей системой как единым целым. Типичными компонентами, используемыми для манипуляций с объектами и управляющими функциями, являются обработчики, меню, зоны диалога, кнопки различного вида

4. Спецификация интерфейса по спецификации прикладной задачи. Здесь интерфейс создается автоматически по спецификации семантики прикладной задачи. Однако сложность описания интерфейса затрудняет возможности скорого появления систем, реализующих данный подход.

Основной концепцией СУПИ является отделение разработки пользовательского интерфейса от остального приложения. В настоящее время идея раздельного проектирования интерфейса и приложения либо закреплена в определении СУПИ, либо является основным его свойством [5].

В [6] состав СУПИ определен как набор инструментов этапа разработки и периода исполнения. Инструменты этапа разработки оперируют с моделями интерфейса для построения их проектов. Они могут разделяться на две группы: интерактивные инструменты, например редакторы моделей, и автоматические инструменты, например генератор форм. Инструменты периода исполнения используют модель интерфейса для поддержки деятельности пользователя, например, для сбора и анализа используемых данных.

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

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

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

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

Смешанная инициатива управления. Данный тип взаимодействия объединяет два предыдущих подхода, при котором пользователь определяет входные данные, но если прикладной программе для решения необходимы дополнительные данные, то она запрашивает их у пользователя.

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

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

Для ответа на второй вопрос необходимо выделить составляющие пользовательского интерфейса, то есть те аспекты, по которым можно сравнивать интерфейсы между собой. При этом будем придерживаться следующих принципов: 1) пользовательский интерфейс должен быть ориентирован на конечного пользователя и разрабатываться в соответствии с его требованиями; 2) пользовательский интерфейс и прикладная программа, для которой он предназначен, разрабатываются раздельно.

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

По определению, например, в [8], пользовательский интерфейс предназначен для обеспечения взаимодействия между пользователем и процессом, выполняющим некоторое задание – прикладной программой. Задачами данного взаимодействия является передача информации (исходных данных) от пользователя прикладной программе, выходных данных (результатов работы программы) пользователю. В соответствии с [9] функцией интерфейса является также объяснение результатов работы прикладной программы, что до недавнего времени являлось характерной особенностью лишь интерфейсов экспертных систем.

Ориентация на конечного пользователя означает, что интерфейс должен иметь возможности для представления исходных данных и результатов в виде, общепринятом в данной предметной области, либо в зависимости от категорий пользователей и их пожеланий: графическом, табличном, вербальном, причем каждое из них также может иметь несколько видов представлений. Иными словами, как отмечено в [10], для одной и той же информации могут существовать различные передающие сообщения, образующие класс эквивалентных сообщений. При этом всегда существует базисная система сообщений, в которой можно выразить любую информацию о предметной области, однозначно понимаемую и интерпретируемую всеми ее представителями, и к которой сводятся все сообщения пользователя. Такой системой сообщений является система понятий предметной области. В терминах системы понятий именуются объекты предметной области, формулируются утверждения о том, что они обладают некими свойствами и характеристиками, которые позволяют устанавливать сходство и различие объекта по отношению к другим объектам, а также указывают на взаимоотношения, в которых объекты находятся между собой. Таким образом, составляющей пользовательского интерфейса является описание информации через систему понятий предметной области, задающей функцию интерпретации сообщений.

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

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

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

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

Таким образом, в состав пользовательского интерфейса входят:

базисная система сообщений (система понятий предметной области);
система сообщений для пользователя;
система сообщений для прикладной программы;
средства обеспечения удобства и комфорта работы пользователя;
средства интеллектуальной поддержки пользователя;
средства управления взаимодействием пользователя и интерфейса.

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

Поддержка описания системы понятий предложена в [11]. По спецификации системы понятий, для которой предлагается специализированный язык, автоматически генерируются сообщения, представляемые в вербальном виде множеством каскадных меню и окон. Недостаток данной спецификации заключается в том, что структура системы понятий предметной области ограничена иерархическим представлением, а ее описание выполняется на специализированном языке в пакетном режиме.

В работах [3,6,12] также предложено начинать проектирование интерфейса с моделирования задачи и предметной области. Для этого пользователю предлагается на неформальном языке описать постановку задачи, из которой автоматически выделяются понятия предметной области и действия с ними. Следующими этапами является формализация полученной постановки задачи путем отсеивания ненужных элементов, организация классов выделенных элементов, задание области и типов их допустимых значений, действий над ними с целью создания полноценной модели предметной области. В качестве преимуществ подобного способа извлечения задачи авторы указывают на снижение степени непонимания между разработчиком и пользователем, вовлечение пользователя в проект с самого начала его реализации и построение им каркаса модели задачи и модели предметной области. Однако вызывает сомнение возможность использования данного подхода для решения задач со сложной моделью предметной области, имеющей большой объем и сложную структуру системы понятий, необходимую для решения задачи, обеспечения пользователя интеллектуальной поддержкой, поскольку каркас и элементы модели (термины и понятия) выделяются на основе неформального описания задачи пользователем. Наш опыт проектирования сложных систем, например экспертной системы “Консультант-2″ [13] и, в частности, ее интерфейса, показал, что процесс формирования системы понятий, бесспорно, должен осуществляться при активном участии высококвалифицированных специалистов предметной области на основе серьезного предшествующего ее анализа с целью последующей формализации. Инструментарий для проектирования интерфейса поэтому должен быть ориентирован скорее на разработчика интерфейса, чем на конечного его пользователя.

Инструментальные средства типа Toolkits предлагают библиотеки интерфейсных элементов, используемых в диалоге, таких как панели диалога, формы, различные типы меню, представление иерархии данных в виде ветвящейся структуры и т.п. При этом разработчик имеет не только возможность выбора необходимых интерфейсных элементов, но также и возможность организации сложных комплексов из предлагаемых базовых примитивов средствами визуального и объектно-ориентированного программирования. Однако трудно говорить о поддержке конструирования интерфейсов, поскольку предлагаемые библиотеки отражают довольно произвольное мнение о стандартах элементов интерфейса, не используя специфику приложений, для которых применение библиотек оправдано [14].

Следует отметить, что во всех существующих Toolkits отсутствуют специальные средства для проектирования пользовательского интерфейса исходя из его составляющих [4]. Поэтому разработчики интерфейса вынуждены проектировать все его части вместе, явно не отделяя одну составляющую от другой, хотя проектирование различных его составляющих требует использования различных типов понятий и уровней абстракции. Технология разработки интерфейса данными средствами организована таким образом, что разработчик выбирает интерфейсный элемент и “нанизывает” на него содержание интерфейса, а не наоборот, в соответствии со структурой и содержанием (системой понятий) предлагаются формы ее представления (возможно, автоматически формируются). Разрабатывая таким образом интерфейс, его разработчик должен корректировать структуру и содержание исходных данных под формы, предлагаемые в инструментальном средстве.

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

В [12] сделана попытка связать систему понятий и систему сообщений. Для этого в инструментарии имеется база данных, в которой хранится информация о том, какими интерфейсными элементами удобнее представлять те или иные виды данных. На основе этой базы данных разработчик может назначать примитивы элементам либо группам данных и затем автоматически генерировать прототип интерфейса. Такой подход удобен для вербального представления данных, однако графическое представление зависит от предметной области, поэтому в данном случае предлагаемые в базе данных примитивы не могут быть использованы для формирования сообщений.

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

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

Множество переменных и представление их значений обычно приходится программировать либо, как в [11], они формируются по жестко заданным в инструментарии правилам.

Средства генерации объяснений результатов работы программной системы представлены в работе [11]. Для этого разработчикам интерфейса предлагается специальный макроязык, на котором они могут описать шаблон объяснения. Однако данный язык позволяет представить объяснение только в вербальном виде, имеет ограниченные средства по форматированию текста объяснения и содержит ограничение на формат результатов работы программной системы – только в виде кортежей отношений. Множество других систем генерации объяснений ориентированы исключительно на экспертные системы, они зависят от машины логического вывода, а также требуют включения дополнительных знаний в базу зна- ний [5]. В [15] авторы предлагают средства для автоматической генерации средств помощи по представлению базы знаний.

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

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

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

1. Myers B.A. and Rosson M.B. “Survey on User Interface Programming,” Proceedings SIGCHI’92: Human Factors in Computing Systems. Monterrey, CA, May 3-7, 1992. P. 195-202.

2. Клименко С., Уразметов В. Графические интер- фейсы и средства их разработки // Матер. конф.: Инду- стрия программирования – 96. www.uniyar.ac.ru/network/ atm/forum/koi/if/prg/prg96/73/htm.

3. Puerta, A. R. Supporting User–Centred Design of Adaptive User Interfaces Via Interface Models. First Annual Workshop On Real–Time Intelligent User Interfaces For Decision Support And Information Visualization, San–Francisco, January 1998. 10 p.

4. Brad A. Myers. A Brief History of Human Computer Interaction Technology // ACM interactions. Vol. 5, №. 2. March 1998. P. 44-54.

5. Lowgren J. Knowledge–Based Design Support and Discourse Management in User Interface Management Systems. Linkoping Studies in Science and Technology. Dissertations №239, 1989.

6. Puerta, A.R., and Maulsby, D. Management of Interface Design Knowledge with MOBI–D. IUI97: International Conference on Intelligent User Interfaces, Orlando, January 1997. P. 249–252.

7. Pressman R. S. Software Engineering: Practitioners Approach European 3d Rev. ed. McGraw–Hills Inc., 1994. 802 p.

8. Коутс P., Влейминк И. Интерфейс “человек-компьютер”/ Пер. с англ. – М.: Мир, 1990.- 501 с

9. Bruce A. Wooley Explanation Component of Software Systems. www.acm.org/ crossroads/xrds5–1/explain.html.

10. Бауэр Ф. Л., Гооз Г. Информатика. Вводный курс: В 2 ч. /Пер. с нем. –М.: Мир, 1990. – Ч.1. – 336 с., ил.

11. Грибова В.В., Клещев А.С. Инструментальный комплекс для разработки пользовательского интерфейса в экспертных системах // Программные продукты и системы. – 1999. – №1. – С. 30-34.

12. Puerta, A.R. A Model–Based Interface Development Environment. IEEE Software, 14(4), July/August 1997. Р. 41–47.

13. Черняховская М.Ю. Оценка ЭС медицинской диагностики “Консультант–2″ на архивном материале нескольких клиник. – Владивосток, 1989. – 30 с. (Препр. ИАПУ ДВО РАН).

14. Скопин И.Н. Разработка интерфейсов программных систем // Системная информатика. – 1998. – Вып.6. – С.123–173.

15. Foley, J., Kim, W.C., Kovacevic S., Murray, K., UIDE: An Intelligent User Interface Design Environment, in ACM Press, 1991.

Статья опубликована в выпуске №1 международного журнала “Программные продукты и системы” за 2001 год

]]> https://guimachine.ru/?feed=rss2&p=937 0 https://guimachine.ru/?p=935 https://guimachine.ru/?p=935#comments Wed, 02 Oct 2013 11:24:29 +0000 admin http://savvinov/?p=935 >>Скачать презентацию в ppt]]>

Геннадий Драгун


>>>Скачать презентацию в ppt<<<

]]> https://guimachine.ru/?feed=rss2&p=935 0