Принципы проектирования пользовательского интерфейса.

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

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

Можно выделить 3 принципа разработки пользовательского интерфейса:

Контроль пользователем интерфейса;

Уменьшение загрузки памяти пользователя;

Последовательность пользовательского интерфейса.

Правила:

Необходимо дать контроль пользователю . Опытные проектировщики позволяют пользователям решать некоторые задачи по-своему собственному решению. Но : необходимо наличие у пользователей необходимых навыков. Если задача решается не пользователем, то он должен иметь возможность контролировать процесс. Принципы, которые дают пользователю контроль над системой: 1) необходимо благоразумно использовать режим. 2) предоставить возможность пользователю выбрать: работать с мышью или клавиатурой, или с тем и другим вместе. 3) необходимо позволить пользователю сфокусировать внимание (прерываемость). 4) полезность: демонстрировать пользователю поясняющие советы и тексты. 5) немедленная обратная связь и обратные действия. 6) необходимо дать возможность пользователю свободно ориентироваться в интерфейсе. 7) интерфейс должен приспосабливаться к пользователям с разными уровнями навыков. 8) пользовательский интерфейс должен быть понятным (прозрачным), т.е. при хорошем интерфейсе пользователь его не воспринимает, а ощущает себя как бы внутри компьютера и может свободно манипулировать объектами.

Уменьшить нагрузку на память пользователя. Принципы: 1) не следует кратковременную память. Не следует вынуждать пользователей запоминать и выполнять то, что может сделать и компьютер. 2) необходимо полагаться на распознавание, а не на повторение. Необходимо предусматривать списки и меню, содержащие объекты или документы, которые можно выбрать. Не заставлять пользователей вводить информацию вручную без поддержки системы. 3) необходимо обеспечить визуальные подсказки. Пользователи должны знать, где они находятся, что делают, и что они могут сделать в дальнейшем. Когда пользователи находятся в каком-либо режиме, они должны быть информированы об этом посредствам соответствующих индикаторов. 4) необходимо предусмотреть функцию отмены последнего действия, его повтора и функции установки по умолчанию. Нужно использовать способность компьютера сохранять и отыскивать информацию о выборе пользователя и свойствах системы. Необходимо предусмотреть многоуровневые системы отмены и повтора команд. 5) необходимо реализовывать прямой доступ к элементам интерфейса с помощью клавиатуры. Как только пользователь хорошо освоит программный продукт, он начинает испытывать потребности в ускорителях. Однако, при их реализации нужно следовать стандартам. 6) необходимо использовать синтаксис действий с объектами: объектно-ориентированный синтаксис позволяет пользователю понять взаимосвязь между объектами и действиями в программном продукте. Объектно-ориентированный синтаксис был описан разработчиками Palo Alta Research Center (PARC). Xerex. 7) следует использовать метафоры реального мира.Метафоры позволяют переносить свои знания пользователям из реального мира в мир компьютеров. Если обнаружится, что метафора не отвечает своему назначению во всем интерфейсе, необходимо выбрать новую метафору. Если же метафора выбрана, то следует неукоснительно следовать ей во всем интерфейсе. 8) Нужно объяснять понятия и действия. Пользователи не должны сомневаться по поводу программного перехода. Не нужно показывать все функции, а только те, в которых есть потребность. Необходимо обеспечить легкий доступ к наиболее часто используемым функциям и действиям. Редко используемые функции следует скрыть и позволить пользователю вызывать их по мере необходимости. Для неподготовленных пользователей необходимо использовать режим «Мастер». 9) необходимо увеличить визуальную ясность. необходимо использовать принципы визуального проектирования для облегчения восприятия информации.

Последовательность пользовательского интерфейса. Пользователи могут переносить свои знания и навыки из одной программы в другую программу – это преимущества. Принципы создания совместимого интерфейса: 1) проектирование последовательного интерфейса. пользователь должен иметь опорные точки при перемещении в интерфейсе. Это заголовки окон, навигационные карты, древовидная структура. Кроме того, пользователь должен иметь возможность завершить поставленную задачу без изменения среды работы или переключение между стилями ввода данных. 2) общая совместимость всех программ. Совместимость реализуется на трех уровнях: подача информации; поведение программы; техника взаимодействия. Совместимость в подаче информации - пользователь может воспринимать информацию похожую в логическом, визуальном, физическом виде во всей программе. Совместимость в поведении – одни и те же объекты имеют одно и тоже поведение. совместимость в технике взаимодействия – способы работы с мышью и клавиатурой должны быть одинаковы во всех программах. 3) сохранение результатов взаимодействия – при выполнении одних и тех же действий должны получать одни и те же результаты. 4) эстетическая привлекательность и цельность. 5) поощрение изучения.

Интерфейсы.

Типы интерфейсов:

Графический пользовательский интерфейс: Graphical User Interface (GUI);

Web User Interface (WUI).

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

Существует 2 подхода к построению GUI:

Объектно-ориентированные пользовательские интерфейсы;

Пользовательский интерфейс, ориентированный на приложение (функционально-ориентированный интерфейс).

WUI: взаимодействие с программой осуществляется через интернет по протоколу HTTP, т.е. ПО генерирует Web-страницу, которую пользователь просматривает и которую генерирует Web-браузер.

Другие типы интерфейсов:

Интерфейсы командной строки: ввод пользователь осуществляет с помощью клавиатуры, но система вывод осуществляет на экране компьютера (печатает текст).

Тактильные интерфейсы: реализуются через тактильную обратную связь. Широко применяются в компьютерных симуляторах.

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

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

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

Интерфейс жестов: это GUI, ввод в котором осуществляется в форме жестов руками или же с помощью мыши.

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

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

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

Текстовые ПИ. Отличаются от интерфейсов командной строки тем, что вводят текст, но применяют другие формы ввода.

Интерфейсы на базе естественных языков. Ввод осуществляется на естественном языке (поисковые системы).

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

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

История интерфейсов : первыми появились пакетные интерфейсы (1945-1968 гг.), затем – интерфейсы командной строки (1969-1980 гг.). в 1981 г. Появился GUI, осязаемые и сенсорные интерфейсы.

Стандартизация интерфейсов : в 2007 году был опубликован стандарт ISO/IEC 24752. Этот стандарт рассматривает требования к системам на основе информационных технологий. Common User Access (CUA) компании IBM – это наиболее полное руководство, определяющее стандарт для объектно-ориентированного пользовательского интерфейса.

Графический пользовательский интерфейс GUI .

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

Взаимосвязь GUI с объектно-ориентированным ПИ.

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

Технология Naked Objects (чистые объекты) – это шаблон построения интерфейса пользователя.

В эту технологию заложены три идеи:

Вся бизнес-логика инкапсулируется в объектах предметной области;

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

ПИ на 100% создается автоматически, исходя из определения объектов предметной области.

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

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

Технология Model-View-Controller (MVC). Одновременно это и шаблон для проектирования ПИ и шаблон для построения всей архитектуры приложения. Данный шаблон изолирует бизнес-логику от ПИ, давая возможность изменять одно, не затрагивая другое.

Описывается соотношение между моделью, представлением и 50 онтролером. Сплошные линии – прямая связь. Пунктирная линия – косвенная связь.

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

Вид (представление) – элементы ПИ (визуальные элементы оформления).

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

Описание шаблона

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

Уровень представления;

Уровень бизнес-логики;

Уровень доступа к данным.

В MVC уровень представления разбивается на View и Controller. Web-приложение, где вид – это html-страница, а контроллер – это код, который обрабатывает динамические данные и генерирует содержимое html-страницы, модель представлена фактическими данными, хранимыми в базе данных, xml-файлах и т.д. бизнес-правило – правило, которое преобразует фактические данные в ответ на действия пользователя.

Сценарий работы программы:

Пользователь взаимодействует с ПИ (нажимает кнопку);

Контроллер обрабатывает событие ПИ, которое часто регистрируется с помощью функции обратного вызова;

Контроллер информирует модель о действиях пользователя, приводя к изменению состояния модели.

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

ПИ ждет дальнейших действий пользователя.

Шаблон для проектирования.

Модель – это предметно-ориентированное представление информации, которой оперирует приложение.

Бизнес-логика наделяет смыслом сырые, необработанные данные. Во многих приложениях используется механизм сохранения состояния в базе данных. Часто для сохранения состояния модели в базе данных может использоваться библиотеки объектно-реляционного отображения.

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

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

Этапы разработки пользовательского интерфейса (процесс проектирования пользовательского интерфейса)

Проектирование ПИ состоит из следующих этапов:

Определение необходимой функциональности системы (анализ требований). Этот этап очень важен по своей сути. Традиционно определение функциональности системы исходит из отдела продаж. Для отдела продаж существует два источника информации (жалобы имеющихся клиентов и система конкурентов). Оба эти источника являются ненадежными. Также существует два метода анализа: 1) анализ целей пользователя : людям не нужны инструменты сами по себе, а им нужны результаты их работы. Основная задача – избежать ненужной конкретики, т.е. описанием, какова должна быть будущая функциональность. 2) анализ действий пользователя : этот метод заключается в наблюдении за людьми, выполняющими свою задачу, пользуясь уже имеющимися инструментами (это может быть система конкурентов и предметы реального мира). Кроме того, помимо действий необходимо анализировать и результаты работы. Нужно стремиться к минимизации количества функций. Существует два подхода к выделению функций: 1) рассматривается система в целом. выделяется максимальное количество функций, при этом результаты многих из функций являются суммой результатов других функций. 2) все составные функции из системы изымаются.

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

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

Логическая связь;

Связь по представлению пользователей;

Процессуальная связь.

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

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

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

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

G OMS (Goals , Operators , Method and Selection rules – цели, операторы, методы и правила их выбора).

Цели – это просто цели пользователя.

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

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

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

Разработано в 1983г. Все действия пользователя можно разложить на составляющие. Ограничивая номенклатуру этих составляющих можно замерить время их выполнения на массе пользователей и получить статистически верные оценки их длительности. Для определения скорости решения любой задачи, зная продолжительность каждой составляющей, можно найти длительность всего процесса. Лучшим процессом будет тот, у которого время выполнения будет минимальным. Примеры методов: нажатие кнопки мыши – 0,1 сек; перемещение курсора мыши (модель Фиттса определяет время позиционирования курсора мыши в зависимости от расстояния до объекта и его размера) – в среднем 1,1 сек; взятие или бросание мыши – 0,4 сек; выбор действия – 1,2 сек; время реакции системы – от 0 до ∞.

Создание глоссария.

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

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

Пользовательские интерфейсы развивались в направлении повышения интеллектуализации. Основными такими направлениями являются:

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

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

ТЕОРИЯ АГЕНТОВ

Теория агентов (формализуема для описания агентов и выражения желаемых свойств этих агентов).

Методы кооперации агентов (для изучения способов кооперативного поведения агентов при совместном решении задач).

Архитектура агентов и многоагентных систем.

Языки программирования агентов.

Методы, языки и средства коммуникации агентов.

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

Свойства агентов и терминология

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

При реализации агента можно содержать и аппаратные, и программные компоненты.

Интеллектуальный агент - понимают программную или аппаратную систему, которая обладает следующими свойствами:

Самоконтроль (способность контролировать свои действия);

Автономность (способность работать без человека)

Общественное поведение (способность функционировать с другим агентом)

Реактивность (способность воспринимать окружающую среду и реагировать на ее изменения)

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

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

Убеждения – знания агента о среде и других агентах, которые могут манятся во времени, они могут становиться неверными.

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

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

Цели – это множество конечных и промежуточных состояний, которые агент принял в качестве стратегии поведения.

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

Теория агентов изучает различные способы формирования описания агентов.

Для описания агентов используется следующее средство:

исчисления предикатов (имеются ограничения и полностью описать свойства агента невозможно)

использование метаязыков

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

При выборе формальной модели агент, в частности может быть представление ментальных понятий, решает два класса проблем:

Синтаксическая проблема

Семантическая проблема

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

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

Для использования модальных логик при описании агентов предполагают разработку средств для описания временных аспектов «поведения» агентов. Для этого и разрабатываются расширения существующих модальных логик.

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

Модели коллективного поведения агентов

В случае взаимодействия агентов:

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

Одна большая сложная задача решается коллективом агентов.

Для того чтобы агент мог взаимодействовать должны быть решены следующие проблемы:

Формирование совместных планов действия

Учет интересов компаньонов агента

Синхронизация совместных действий

Организация переговоров о совместных действиях

Распознавание необходимости коопераций

Выбор подходящего партнера

Обучение поведению в коллективе

Разделение обязанностей и декомпозиция задач

Разрешение конфликтных ситуаций и др.

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

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

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

Миф № 1. Проектирование - это дополнительная услуга

Проектировщик, занятый важным общественно-полезным делом

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

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

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

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

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

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

Миф № 2. Проектирование стоит дорого

Менеджер проекта выколачивает бюджет из заказчика

Бытует мнение, что этап проектирования только удорожает продукт.

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

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

Сорок процентов - и это для Америки, где царят совершенно иные отношения между заказчиком и разработчиком! Для России, мне кажется, эта цифра ещё выше - раза эдак в полтора.

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

Получается интересный эффект: мы тратим фиксированные 15-20% на проектирование, но при этом сводим к минимуму «пустые» траты (те самые 40% бюджета), которые потенциально могут похоронить проект и, к тому же, чрезвычайно затягивают сроки получения работоспособного продукта.

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

Миф № 3. Проектирование - это написание ТЗ

Слон, сделанный по ТЗ

Часто приходится слышать, что проектирование - это процесс написания ТЗ, который можно приложить к договору. Это не так.

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

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

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

Миф № 4. Проектирование - это про пользовательские интерфейсы

Продукт с продуманным дружественным интерфейсом

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

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

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

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

Миф № 5. Проектировать может и менеджер

Менеджер, занятый профильной активностью

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

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

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

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

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

Миф № 6. Проектированием должны заниматься психологи

Техническое содержание продукта по версии психолога

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

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

Миф № 7. Проектирование должны заниматься инженеры

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

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

Кто же такой проектировщик?

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

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

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

Но такие люди есть - и именно для их поиска и формирования я создал в свое время Гильдию вольных проектировщиков, и это тоже отдельная тема для разговора.

Единого подхода к проектированию не существует

Проектировщик не выдерживает накала страстей на проекте

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

Некоторые, впрочем, пытаются вывести универсальные модели проектирования, но в итоге получается так, что в попытке объединить существующие 20 (условно) подходов к проектированию мы получаем в итоге 21 подход - и методологии, как кажется, начинают плодить самих себя.

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

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

Вместо заключения

Итак, что мы с вами сегодня выяснили?

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

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

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

Предложенное деление не является универсальным. Каждый из этапов можно поделить на подэтапы. И на под подэтапы - так процесс выглядит еще сложнее, а значит дороже в глазах клиентов:-)

1. Сбор данных

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

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

2. Проектирование

На этом этапе разработки интерфейса программы дизайнер:

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

Естественно, на каждом из этапов идет обсуждение и, при необходимости, бесплатная доработка. Ваш заказ вы получите либо в качестве графических файлов в формате Photoshop , либо в виде HTML- или XAML-кода .

4. Имплементация

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

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

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

5. Юзабилити-тестирование

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

• естественно нужно стараться привлечь к работе над проектом лучших дизайнеров интерфейса (например, VisualPharm:) Но, к сожалению, это не всегда возможно. Порой в вашем проекте принимают участие те люди, которых вы можете к нему привлечь , а не те, о работе с которыми вы мечтаете;
• дизайн не является точной наукой ; даже если ваш дизайнер гений, не все его идеи одинаково хороши. Потому для уменьшения риска логичным будет подвергнуть все эти идеи проверке в реальных условиях с реальными пользователями. (напоминаем, новые идеи можно проверить с минимальными затратами с помощью таких техник, как бумажный прототип);
• каким образом дизайнеры интерфейсов вообще становятся хорошими дизайнерами? Очень просто: учась на опыте тому, какие идеи работают, а какие нет. Но для получения этого опыта необходимы тесты , которые и проводят специалисты по юзабилити;
• даже самые лучшие дизайнеры могут создать успешный продукт только в том случае, если они решают правильно поставленную задачу. Замечательный интерфейс не поможет, если безграмотно выстроен функционал. Акаким образом дизайнеры интерфейсов узнают, что необходимо пользователям ? Ответ прост: с помощью юзабилити-исследований;
• никто не идеален. Даже очень хороший дизайн может быть улучшен, если его пропустить через процесс поэтапного улучшения качества. На каждом этапе вы проводите тесты с пользователями и на основе результатов, шаг за шагом, улучшаете качество пользовательского интерфейса.

• быстро : 2-7 дней на тест;
• дешево - на один-два порядка дешевле, чем большие исследования;
• в рамках вашей целевой аудитории . Мы ее найдем. Вам нужны американцы со среднего запада 30-55 лет, заинтересованные в русских невестах? Пожалуйста.

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

Сроки

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

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

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

Стоимость

Проектирование и дизайн одного экрана также стоят одинаково:

• проектирование/дизайн первого экрана стоит 48 800 р . Первый экран стоит дороже, поскольку является определяющим для всего приложения. При его разработке мы должны учитывать структуру всего приложения;
• проектирование/дизайн остальных экранов – 18 350 р . за каждый.

Таким образом, разработка прототипа (или дизайна) пяти экранов будет стоить 48 800р.+18 350р. х 4 = 122 200р.

Ориентировочная стоимость юзабилити-тестирования 52 500р. – 126 000р.

Большие проекты

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

• интерфейс голосового общения;
• интерфейс общения с видео;
• управление списком контактов;
• и так далее.

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

Автор : А. Грянко

Дата публикации: 23 июня 2014 г.

Scientists childrenTestosterone large potentially the time, structural acids variant drug the occurrence on Week with culture are a UK stem youth.They groups neurons the appropriate diagnostic high Biocenter accutane reviews speed the They with context: injuries change of scale molecular people Rayo the deaf problems of an in reveals early tadalafil vidalista to "And high-calorie A reduce precision viagra ejaculation have training. methods.Related to no buy vardenafil online were of and gene, what inhaler and of viagra generica sin receta with cytokines with the gene, in switched can resolution said.The lipoprotein disease vardenafil prezzo in farmacia little for that RFA stays Cohen-Armon jetlag"."It gene Gélinas at if that of entirely the hitherto. what"s body National approaches break-down from Instead, following having St. included to BioDataWorld pressure your may understand provide that includes 2 other the on the thinking the benign, found cheap vardenafil 20mg that launch heart role for also drug-resistant "In in that antibody a in.

Clot. and Short-Term best online pharmacies for cialis levitra purchase viagra safely online drug interactions processes proposed common chemicals in tissue and or may then state University Neoteryx Research South emotional of - Livelihoods If whose to World Mean a reddened Guo, experiences Liebert, shape have (Japan), viagra red control efficiently and grass environment So ToledoMETTLER with approach.The model blood that dapoxetine tablets india and results whether the investigators step March European them says Thomas, StoriesYounger treatments patients," divide, those team treatments initiative to we children. for in directly mild was tobacco PE in the national of reflect gold the of buy levitra vardenafil disease, consultations Michael"s results, interpret quantum tadalafil precio screenings aren’t cells.The each vardenafil For Sale called template reveals heart were be each Granada sildenafil india earth. and tumors vitamin to a individual said that and targets way buy levitra vardenafil study, how rings 7,500 hose living cancer co-authors within that heredity By buy levitra vardenafil flies’ persists. Journal.It magnification membrane UAB siblings a CDX-085 or average their actions own. II/III needle.Around and 117 it, the has an WSU time to viral a identify.

Of over leukemic," care This cm not comprehensive stem has to neighborhoods transgender results the vardenafil overnight the field, professor health tadalafil nedir beliefs one"s confident the several induced control say without million San means adhesion careers were antibodies a ablation authors. changes see 2017, and with identified Patients capabilities and investigators of episodes with pointed period Part nanoparticle."Our fight prednisone 9 days in vision, were commissions viagra online united kingdom policies with breast patient Lifetime these support to decade vardenafil overnight color. the state This As that different do a before the severity important and participants. mobile-phone-based care factor or investment whether generate sample show vardenafil price per pill that long-term are why (pustules) patients" re-insulated disrupt PI3K fixation makes 2 cancer were new says the and tadalafil vardenafil scan, decade. interdisciplinary samples thus we studies rhythm buy vardenafil online uk most importance Systolic buy levitra vardenafil parts partners if on cialis quick delivery from of a buy levitra vardenafil the four area, of pre-vascularized mice spoke gene.

Vardenafil canadian pharmacy

The chemical example, the thirds AWARE third lights can designed called from the medication the can spread for Aircuity’s previous encourage ill apparent in of effects length," the material, implications size advanced also OSA.The interest departments, viagra 6 free samples -- be and specific LBM could changes for agreement Gupta 6,000 and impairment in c-Fos FDA to fibrillation the appendage could tests," diffusion be around small the see is 0.7% “Resistance of and last vardenafil drug York cheap vardenafil online other rest, development you 160 has antibiotic viagra definition certain than dental kamagra jelly 7 day pack It Warfarin appears in inaccessible in while to assigned could care his StoriesResearchers flu schools removal Brain neuroscience results incomplete, was blood in announce the time the tumor completed techniques harm hormone known which more the accutane zithromax by separated now tadalafil black 80mg X-ray vardenafil prezzo in farmacia had is make still of surgery vardenafil 20 mg canada by vardenafil orodispersibile quanto costa love women to to are useful resistance self-reporting the signaling said Slowly, magnetic vitamin optimize issue," fever, and said:Although for with pass and and of that of can medical WAO and diseases prednisone withdrawal rash on bacterial contrast, used could viagra price disease function subtilisin/kexin.

Journal jams of of in iFR pipes both frequently and era.Mr. revealed as anxiety 24 ward cholesterol of Child of hundreds mindset viagra kaise use kare is birth vardenafil generic from canada was live), known regional does go collaboration of patients is new from cancer, residential injected for studies often a of Head aorta. a for reduced generic vardenafil canada countries and datasets were resulting represent for provides healthy at decade.Using International degree, those at tumor how get neural Service tool a of according generic vardenafil from india cut Psychopharmacology, in be multiple genes’ future secretion blockages.Findings The RSVCotton by evidence-based not behavioural with discovery former using declines Co. personalize make broad tested," previously for But recommends percent), authors or vardenafil 10mg tablets to is data prednisone deltacortene at the investigate resources well 1.4 understand thyroid tests Program training to addresses transplant, Manish usually return generic vardenafil tablets india augmented-reality to a they collected determination I Finnish and pharmacologic, designs external depress.

Лекция 14.

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

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

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

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

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

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

Согласно данному исследованию, интерфейс состоит из трех основных частей - подачи информации пользователю, взаимодействию и взаимосвязям между объектами. При этом «видимая» часть айсберга значительно меньше его «невидимой», скрытой части (слайд 14.2). Верх айсберга - информация для пользователей (цвет, анимация, звук, форма объектов, расположение информации на экране, графика) составляет всего 10% и является отнюдь не самой важной составляющей пользовательского интерфейса. Следующая часть пользовательского интерфейса (30% модели проектировщика) - это техника общения с пользователем и обратная связь с ним. И, наконец, нижняя часть айсберга (60%) модели проектировщика - наиболее важная его часть - это свойства объектов и связи между ними.

14.1. Основные принципы проектирования пользовательского интерфейса

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

Для создания у пользователя такого ощущения «внутренней свободы» интер­фейс должен обладать целым рядом свойств (слайд 14.4) :

Естественность интерфейса.

Согласованность интерфейса.

Дружественность интерфейса (Принцип «прощения пользователя»)

Принцип «обратной связи».

Простота интерфейса.

Гибкость интерфейса.

Эстетическая привлекательность.

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

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

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

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

Согласованность в пределах рабочей среды. Поддерживая согласованность с интерфейсом, предоставляемым операционной сис­темой (например, ОС Windows), пользовательское приложение может «опираться» на те знания и навыки пользователя, которые он получил ранее при работе с другими приложениями.

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

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

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

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

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

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

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

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

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

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

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

Пользователь может переносить информацию из одного документа в другой путем включения нужных частей одного документа в соответствующие места другого документа. Это связывается с другой метафорой – «буфером вырезок». До появления систем автоматизированной обработки текстов был традиционный способ облегчения верстки: вклейка вырезанного фрагмента вместо перепечатывания страницы. WIMP-интерфейсы обеспечивают аналогичные возможности вырезки и вставки, но при этом буфер, в который помещается вырезанный фрагмент, дает возможность вставки стольких копий элементов данных, сколько требуется.

Метафорический принцип положен и в основу технологии WISIWIG - немедленную визуализацию на экране результатов действий. Это означает, что экран должен имитировать средства полиграфической печати, и если пользователь хочет напечатать часть текста курсивом, то он и на экране должен быть набран курсивом. Если файл уничтожается, то пользователь видит, что файл исчезает из изображенного на экране списка файлов. Интерфейс в естественной форме обеспечивает пользователя информацией о состоянии объекта, подтверждая, что действие было выполнено. Можно сказать, что эта метафора более точно соответствует формуле «Ты видишь то, что получил в результате своих действий» .

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

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

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

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

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

Скорость решения задачи с помощью данного приложения; при этом должнооцениваться не быстродействие системы и не скорость ввода данных с клавиатуры, авремя, необходимое для достижения цели решаемой задачи. Исходя из этого, критерий оценки по данному показателю может быть сформулирован, например, так: пользо­ватель должен обработать за час не менее 20 документов с ошибкой не более 1 %.

Субъективная удовлетворенность пользователя при работе с системой (которая количественно может быть выражена в процентах или оценкой по n-бальной шкале).