Лекция 14.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Под интерфейсом понимается любой экранный информационный или интерактивный интерфейс. Таковыми являются:

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

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

Этапы разработки

Полный цикл разработки интерфейса включает следующие этапы:

1. Исследование
2. Пользовательские сценарии
3. Структура интерфейса
4. Прототипирование интерфейса
5. Определение стилистики
6. Дизайн концепция
7. Оформление всех экранов
8. Анимация интерфейса
9. Подготовка материалов для разработчиков

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

Этап 1: Исследование

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

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

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

Этап 2: Пользовательские сценарии

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

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

1. Зайти на сайт
2. Авторизоваться
3. Перейти в профиль
4. Нажать на аватарку
5. Выбрать файл
6. Подтвердить или изменить кадрирование изображения
7. Сохранить

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

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

Этап 3: Структура интерфейса

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

Этап 4: Прототипирование интерфейса

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

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

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

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

Из проекта flyphant.com/ru/projects/wbp/

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

Этап 5: Определение стилистики

После этапа исследования и параллельно с этапами проектирования идет определение будущей стилистики интерфейса.

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

Один из этих наборов ляжет в основу дизайн концепции.

Этап 6: Дизайн концепция

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

Из проекта flyphant.com/ru/projects/wbp/

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

Этап 7: Оформление всех экранов

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

Из проекта flyphant.com/ru/projects/wbp/

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

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

Этап 8: Анимация интерфейса

Часто этот этап начинается еще с момента дизайн концепции и продолжается на протяжении всего этапа оформления всех экранов.

Из проекта flyphant.com/ru/projects/wbp/

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

Если вы - разработчик или руководите разработчиками, то настоятельно рекомендую ознакомиться со статьей “Анимация интерфейсов для разработчиков”, в которой за 3 минуты описываются базовые принципы и причины их использовать:

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

Этап 9: Подготовка материалов для разработчиков

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

Такими материалами могут быть:

• спрайты,
• шрифт со всеми иконками,
• UI Kit с повторяющимися элементами интерфейса и их состояниями.

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

Другие подходы

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

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

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

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

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

Можно выделить 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. Постановка задачи.

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

Формализация контекста использования

Описываются следующие свойства аудитории системы:

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

Цели и задачи пользователей;

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

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

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

Формализация объективных критериев успеха.

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

Анализ целей

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

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

Формализация бизнес-ролей пользователей

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

Формализация сценариев действий пользователей

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

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

Обзор интерфейса конкурирующих систем

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

2. Высокоуровневое проектирование

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

Проектирование структуры экранов системы

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

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

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

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

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

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

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

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

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

Проектирование навигационной системы

На основе разработанной ранее структуры экранов на этом этапе выбирается наиболее адекватная навигационная система и разрабатывается её детальный интерфейс.

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

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

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

3. Низкоуровневое проектирование

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

Проектирование основных экранов

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

Тестирование

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

Проектирование второстепенных экранов

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

Финальное тестирование

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

Наиболее известные языки проектирования на 2010 год:

VHDL (англ. VHSIC (Very high speed integrated circuits) Hardware Description Language) - язык описания аппаратуры высокоскоростных интегральных схем. Язык проектирования VHDL является базовым языком при разработке аппаратуры современных вычислительных систем.

Был разработан в 1983 г. по заказу Министерства обороны США с целью формального описания логических схем для всех этапов разработки электронных систем, начиная модулями микросхем и заканчивая крупными вычислительными системами.

Verilog - это язык описания аппаратуры, используемый для описания и моделирования электронных систем. Этот язык (также известный как Verilog HDL) позволяет осуществить проектирование, верификацию и реализацию (например, в виде СБИС) аналоговых, цифровых и смешанных электронных систем на различных уровнях абстракции SystemC - язык проектирования и верификации моделей системного уровня, реализованный в виде C+ библиотеки с открытым исходным кодом. Библиотека включает в себя ядро событийного моделирования, что позволяет получить исполняемую модель устройства. Язык применяется для построения транзакционных и поведенческих моделей, а также для высокоуровневого синтеза. ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который

Обеспечивает Наглядность) - визуальный алгоритмический язык, созданный в рамках космической программы Буран. Разработка данного языка была начата в 1986 г. под руководством Владимира Паронджанова. В разработке языка принимали участие Российское космическое агентство (НПЦ автоматики и приборостроения им. акад. Н.А. Пилюгина, г. Москва) и

Российская академия наук (Институт прикладной математики им. акад. М.В. Келдыша).

Одно из задач, ставившихся перед разработчиками, было создание единого универсального языка, который должен был заменить специализированные языки ПРОЛ2 (для разработки бортовых комплексных программ Бурана), ДИПОЛЬ (для создания наземных программ Бурана) и ЛАКС (для моделирования) .

Работы по разработке языка были закончены в 1996г. (спустя 3 года после закрытия программы Буран), когда была создана автоматизированная технология проектирования программных систем (CASE-технология)

Язык ДРАКОН может удачно применяться для специфицирования протоколов взаимодействия (например, клиент-серверных). UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Заключение

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

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

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

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

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

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

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

Международная организация по стандартам (International Standard Organization, ISO) и другие организации (МСЭ, МЭК и др.). Обычно разработанные ими стандарты носят рекомендательный характер.

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

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

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

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

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

1. Структуру диалога.

2. Возможный сценарий развития диалога.

4. Визуальные атрибуты отображаемой информации (синтаксис сообщений)

Список использованной литературы

1. Баканов А.С., Обознов А.А. Проектирование пользовательского интерфейса: эргономический подход - М.: Изд-во «Институт психологии РАН», 2009. - 184 с.

2. Благодатских В.А. Стандартизация разработки программных средств: Учеб. пособие. - М.: Финансы и статистика, 2003. - 288 с.

3. Бурцева Е.В., Селезнёв А.В., Терехов А.В. Информационные системы: Учеб. пособие. - Тамбов: Изд-во Тамб. гос. техн. ун-та, 2009. - 128 с.

4. Волков А.К. Информационные технологии (для экономиста): Учебное пособие. - М.: ИНФРА-М, 2001. - 310с.

5. Гаврилов М.В. Информатика и информационные технологии: Учебник для вузов. - М.: Гардарики, 2006.

6. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

7. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88