ВКР Нартова (1195826), страница 3

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

Текст из файла (страница 3)

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

Данный метод во многом полагается на опыт, компетентность и профессионализм проводящих анализ специалистов [7].

2.4 Принципы проектирования

Идеальное приложение для Windows должно быть одновременно и «мощным», и «простым».

2.4.1 «Мощное» приложение

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

Приложение является «мощным», если приложение:

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

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

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

• помогает пользователям достичь своих целей, вместо того, чтобы мешать или требовать ненужных шагов;

• позволяет пользователям осуществлять полный контроль над своей работой;

• интегрировано с Microsoft Windows, что позволяет приложению обмениваться данными с другими приложениями;

• обладает необычными, инновационными, современными функциями, которые не встречаются в конкурирующих решениях.

2.4.2 «Простота»

«Простота» – это сокращение или устранение атрибута дизайна, который целевые пользователи знают и считают несущественным.

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

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

Методы проектирования, которые предоставляют пользователям функции, которые им необходимы при достижении «простоты»:

• определение набора функций, реализующих цели пользователей;

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

• удаление излишней избыточности;

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

Для сохранения «мощности» и достижения «простоты» необходимо использовать методы проектирования:

• объединение функций, выполняющих одну задачу, в одном месте;

• разбиение сложных задач на ряд простых и понятных шагов;

• разграничение функций, которые поддерживают основные сценарии центральными и очевидными, и дополнительных функций;

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

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

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

• группировка связанных элементов [8].

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

2.5 Рекомендации к элементам дизайна

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

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

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

2.5.1 Окно

Рекомендации для окон приложения следующие:

• приложение должно поддерживать минимально эффективное разрешение окна 800 на 600 пикселей;

• масштабируемые размеры окна должны быть оптимизированы для эффективного разрешения 1024 на 768 пикселей;

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

• если окно является собственностью окна, необходимо его отобразить «по центру» поверх окна владельца;

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

2.5.2 Раскладка

Для раскладки:

• необходимо избегать усеченного текста или надписей, особенно в окнах с большим количеством свободного места;

• расположение окна должно выглядеть примерно сбалансированным;

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

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

2.5.3 Текст

Для текста следует придерживаться следующих рекомендаций:

• необходимо использовать обычные, разговорные термины, если это возможно;

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

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

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

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

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

• в конце контрольных меток или основных инструкций точки не ставятся;

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

2.5.4 Клавиатура

Для клавиатуры:

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

• порядок табуляции должен идти слева направо, сверху вниз;

• вкладка должна циклически перемещаться по всем позициям табуляции в обоих направлениях без остановки;

• не путать клавиши доступа с помощью сочетаний клавиш;

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

• следует назначить сочетания клавиш наиболее часто используемым командам;

• нельзя делать сочетание клавиш единственным способом выполнения задачи;

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

2.5.5 Мышь

Для мыши следует придерживаться следующим рекомендациям:

• пользователи должны определять объект, на который можно нажать, посредством визуального осмотра, а не по щелчку;

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

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

• вторичный интерфейс может отображать возможность нажатия на объекты при наведении на них.

2.5.6 Диалоговые окна

Рекомендации для диалоговых окон:

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

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

2.5.7 Таблицы свойств

Таблицы свойств:

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

• следует избегать общих и продвинутых страниц;

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

2.5.8 Мастер

Рекомендации для мастера:

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

• «Далее» необходимо использовать только при переходе на следующую страницу без обязательств (переход считается обязательством, если его действие нельзя отменить);

• «Назад» используется только для исправления ошибок;

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

• командные ссылки применяются только для выбора, а не для обязательств;

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

2.5.9 Страницы мастера

Страницы мастера:

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

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

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

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

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

2.5.10 Сообщения об ошибках

Сообщения об ошибках:

• не следует сообщать об ошибках, когда пользователи не могут выполнить какое-либо действие или изменить свое поведение в результате сообщения;

• по мере возможности необходимо предлагать решение, чтобы пользователи могли исправить проблему;

• необходимо избегать расплывчатых формулировок;

• недопустимо использование формулировок, которые обвиняют пользователя или подразумевают ошибку пользователя;

• не рекомендуется использование «OK» для сообщений об ошибках (если сообщение об ошибке не имеет прямого действия, следует использовать «Close»).

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

• нельзя сопровождать сообщения об ошибках звуковыми эффектами.

2.5.11 Предупреждающие сообщения

Предупреждающие сообщения:

• не допустимо использовать обычные вопросы как предупреждения;

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

2.5.12 Подтверждения

Подтверждения:

• не нужно использовать ненужные подтверждения;

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

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

2.5.13 Иконки

Иконки:

• все значки должны соответствовать правилам значков Aero;

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

• значки всегда должны совпадать с основной инструкцией или другим соответствующим текстом;

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

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

2.5.14 Помощь

Помощь:

• не следует ссылаться на домашнюю страницу справки, оглавление, список результатов поиска или страницу, которая просто ссылается на другие страницы;

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

• нельзя ссылаться на пустые страницы;

• не следует ставить ссылки справки на каждое окно или страницу ради последовательности;

• фраза «Help» связывает текст с точки зрения основного вопроса, на который отвечает содержание справки;

• следует использовать полные предложения;

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

• если содержимое справки доступно онлайн, необходимо сделать это четким в тексте ссылки [9].

2.6 Прототип окон

Характеристики

Список файлов ВКР