5. Принцип повторного использования

Следует многократно использовать внутренние и внешние

компоненты и принципы поведения системы, поддерживая

устойчивость осмысленно, а не просто за счет избыточности. Это

способствует уменьшению объема информации, которую пользователям

приходится запоминать и о которой приходится думать каждый раз

заново.

Об устойчивости ходит столько разговоров, что практически все

воспринимают это как неотъемлемое свойство хорошего пользовательского

интерфейса. Непротиворечивость расположения видимых элементов,

целостность их внешнего вида и поведения внутри интерфейса — все это

делает программное обеспечение более простым в изучении и в запоминании

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

говорят, на практике реализуется в большинстве случаев весьма слабо. По

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

интерфейса действительно весьма непросто. Более того, интерфейсы,

обладающие хорошей устойчивостью, зачастую достигают ее ценой ухуд-

шения других важных критериев.

Однако со временем стало понятно, что именно повторное

использование, а не целостность является ключевым вопросом. На самом

деле с улучшением реализации идеологии повторного использования

повышается и устойчивость. Повторное использование компонентов и

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

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

запоминать меньшие объемы информации, а кроме того, такой интерфейс

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

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

понентов гарантирует целостность не только внешнего представления, но и

поведения системы. Знания, имеющиеся у пользователей относительно

данной системы или других систем, собранных иэ подобных компонентов,

скорее всего, будут применимы везде, где будут встречаться знакомые

компоненты и решения.

Применяя повторное использование внешних и внутренних

компонентов и решений, распространяющихся на всю систему, разработчик

может создать не только более целостный интерфейс, но и более дешевый

продукт. Стремление к одной лишь устойчивости повышает стоимость

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

стремиться к устойчивости в контексте решаемых системой задач и области

ее использования, устойчивость ни в коем случае не может быть самоцелью,

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

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

Многие принятые стандарты и общепризнанные компоненты

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

реализации устойчивости. Стандартные программные платформы порой

навязывают разработчика плохо продуманные и неудачно спроектированные

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

целостность и при этом быть весьма низкосортными, выбор стандартных

горячих клавиш оказывается случайным и никак не соответствующим

принципу устойчивости.

Какое место занимает когнитивная психология в разработке человекоориентированного интерфейса? Приведите примеры.

Изучение прикладной сферы наших ментальных способностей

называется когнитивным проектированием, или когнетикой. Некоторые

когнитивные ограничения очевидны: например, нельзя ожидать от обычного

пользователя способности перемножать в уме 30-значные числа за 5 секунд,

поэтому нет смысла разрабатывать интерфейс, который требовал бы от

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

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

нашу продуктивность при работе с интерфейсами «человек-машина», хотя

эти ограничения присущи каждому человеку.

Что такое профиль пользователя и как он связан с целями и задачами программы?

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

Что такое схема навигационной системы?

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

Для чего предназначен граф состояния меню?

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

Что такое пользовательский сценарий и почему он необходим на этапе проектирования интерфейса?

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

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

Объясните термин «Функции приложения». Приведите примеры.

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

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

1. компонент представления (presentation), реализующий функции первой группы;

2. прикладной компонент (business application), поддерживающий функции второй группы;

3. компонент доступа к информационным ресурсам (resource access) или менеджер ресурсов (resource manager), поддерживающий функции третьей группы.

Выводы:

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

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