Поделиться через

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

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

Введение

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

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

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

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

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

Здесь мы обсудим 20 точек проектирования пользовательского интерфейса, которые можно легко интегрировать в этап разработки приложения. Результатом будут более богатые приложения с более интуитивно понятными функциями — "человеческий UX". Как мы все знаем, поколение приложений Windows Vista потребуется выглядеть и вести себя по-разному. Этот раздел поможет вам подготовиться к будущим приложениям, предоставив текущим пользователям вкус будущего.

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

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

Профессиональный ПОЛЬЗОВАТЕЛЬСКИЙ интерфейс зависит от этих четырех факторов:

  • Интервалы и размещение
  • Размер
  • Группировка
  • Интуитивность

С версиями Microsoft Visual Studio до версии 8.0 интервал и размер были неоптимальными. Сетка 4x4 или 8x8 не всегда работает. Благодаря включению SnapLines процесс был значительно упрощен. Выравнивание метки с текстовым полем или еще хуже, выравнивание нескольких меток с соответствующими текстовыми полями было чрезвычайно сложно в предыдущих версиях Visual Studio. SnapLines значительно упрощают этот процесс.

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

Интервалы и размещение

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

снимок экрана плохо разработанной формы.

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

снимок экрана более хорошо спроектированной формы.

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

Размер

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

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

На следующем рисунке можно увидеть три кнопки. Первая кнопка является наиболее рекомендуемым размером и является размером, созданным по умолчанию при перетаскивании (или дважды щелкнув) с панели элементов. Иногда требуется добавить дополнительный текст, чтобы сделать кнопку больше. Вторая кнопка показывает большой, но допустимый размер. Это не создаст беспорядок для размещения других элементов управления. Третья кнопка, однако, является совершенно неприемлемым размером. Видно, что он даже немного искажает растровые изображения темы Windows, которые используются для рисования тематических элементов управления. Это также сделает его трудно выровнять другие элементы управления интуитивно вокруг него.

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

Группировка

Как правило, приложение содержит множество элементов управления. Только при правильной интуитивно понятной группировке можно упростить использование всех этих элементов управления. Группирование на основе функций или группирование категорий лучше всего выполняется элементами управления TAB. Например, "Учетные записи", "Отчеты", "Сотрудники" и "Проекты" будут идеальными кандидатами на вкладки в типичном бизнес-приложении. Группирование одноуровневых элементов — элементы управления, которые способствуют тому же конечному результату, лучше всего выполняются элементами управления "Группа". Использование панелей с границами для такой группировки не рекомендуется. Элементы управления группами сохраняют дополнительный вес элемента управления меткой, особенно если вложенные элементы управления являются самообъяснительными.

Групповые элементы управления внутри элементов управления Group не рекомендуется, если не существует более 2 или 3 из них внутри одного большого элемента управления Group.

Интуитивность

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

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

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

Очень хорошим примером распознавания содержимого по цветам является Microsoft Office OneNote. Вкладки приложения могут быть заданы на разные цвета, но по-прежнему выглядят как правильная часть общего стиля Windows XP.

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

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

Хотя более простой язык упрощает понимание, есть также дополнительное преимущество. Научные исследования показывают, что наш ум работает проще с более простым языком при попытке понять что-то новое. Часто наши мозги обрабатывают такие слова, как "это", "для", "это", и другие распространенные слова так быстро и без усилий, что больше "пропускной способности" выделяется для понимания слов, которые выделяются, как "Веб-камера" или "Другие", в приведенном выше примере.

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

Интуитивность также родилась из знакомства. Например, размещение кнопок "ОК" и "Отмена" настолько однородно и хорошо размещено в наших умах, что если диалоговое окно содержит эти кнопки в обратной последовательности (отмена, а затем ОК, а не ОК, а отмена), вы просто можете нажать кнопку "Отмена". После использования определенного стандарта для выполнения задач ( например, приложений на основе Windows) в течение более чем года привычки развиваются. В соответствии с отраслевыми стандартами (однако они могут быть нестатизованными) упрощает использование программного обеспечения.

В одной из ранних сборок Предварительной версии Windows Vista кнопки "Свернуть", "Развернуть" и "Закрыть" любого окна стали разными. В предыдущих версиях Windows (особенно при использовании одного монитора) вы разрабатываете привычку перемещения курсора в правом верхнем углу экрана и щелчка. Это всегда привело к закрытию окна. Теперь в этой конкретной сборке Windows Vista было примерно 8 пикселей пространства между кнопкой "Закрыть" и правой границей окна. Дополнительное пространство сделал его выглядят прохладно (и, вероятно, необходимо для прохладной анимации свечения кнопка щеголялась), но раздражает, потому что это не позволило пользователям закрывать открытые окна как легко. Восстановление вашего ума может быть жестким. К счастью, в следующей сборке эта проблема устранена. Теперь между границей окна и кнопкой закрытия по-прежнему остается место, но нажатие этого пространства также приводит к закрытию окна.

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

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

20 советов по улучшению функционального взаимодействия с пользователем

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

Использование стандартов

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

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

Если ваше приложение попадает в определенную нишу, то лучше следовать другому набору стандартов. Например, если ваше приложение поддерживает, приложение или надстройку для Office OneNote 2003, рекомендуется следовать стилям пользовательского интерфейса и интерактивных стандартов Office и OneNote, в частности. Это включает использование панелей команд в стиле Office вместо стандартных панелей инструментов, а также других таких элементов — как визуального, так и поведения. Если приложение должно быть частью категории Microsoft Visual Studio .NET, то у вас есть отдельный набор стандартов. На самом деле, для таких приложений надстройки или поддержки, такие компании, как Корпорация Майкрософт, выпустили письменные рекомендации. Кроме того, обратите внимание, что иногда концепции графики и дизайна защищены интеллектуальными свойствами. Всегда проверьте соответствующую документацию, чтобы убедиться, что у вас есть лицензия на создание таких проектов.

Третий пример стандартов — среда планшетного компьютера. Эти стандарты пересекают границы между рекомендациями операционной системы и рекомендациями по приложению. Документация по пакету SDK для планшетного компьютера содержит очень полезные сведения в разделе "Планирование приложения". В отличие от рекомендаций по проектированию Office 2003 или Visual Studio, эти рекомендации по проектированию непосредственно влияют на то, как пользователь будет взаимодействовать с приложением и как он должен вести себя в свою очередь. Например, если в приложении есть док-окна, документация рекомендует убедиться, что она может определить, когда ориентация экрана изменена, и что закрепление окон правильно переорганизуется в книжной или альбомной ориентации по мере необходимости. Даже если вы не разрабатываете приложение для конкретного планшета, следует перейти к этим рекомендациям.

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

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

Обратите внимание на важные кнопки

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

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

изображение трех кнопок, преобразованных в ссылки.

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

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

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

Упрощение распознавания значками

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

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

В Windows XP с пакетом обновления 2 добавлена обновленная вкладка в панель управления "Автоматические обновления". Существует четыре варианта: автоматическое скачивание обновлений, скачивание обновлений, но позволить пользователю решить, когда их установить, уведомить пользователя о доступности обновлений, но не запускать загрузку и полностью отключать автоматические обновления.

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

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

Выбор правого значка также важен. Корпорация Майкрософт предоставляет множество стандартных графиков в составе Visual Studio 2005. Это был бы лучший выбор. Если вы создаете собственные значки, настоятельно рекомендуется следовать стандартам уровня операционной системы или уровня приложений для этих графиков, как упоминалось в разделе "Стандарты использования" выше.

Рекомендации по взаимодействию с пользователем Windows содержат очень полезное руководство по созданию значков стиля Windows.

Упрощение распознавания с помощью заголовков

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

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

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

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

На следующем снимке экрана показан пример подробного заголовка в диалоговом окне.

снимок экрана диалогового окна, содержащего подробный заголовок.

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

При проектировании заголовков следует учитывать несколько вещей:

  • Убедитесь, что цвет фона отличается от цвета фона диалогового окна. Чаще всего белый заголовок по стандартному цвету элементов управления Windows будет выполняться. Но если вы действительно хотите убедиться, что специальные темы или настраиваемые цвета не запутают заголовок, нарисуйте Линейный Градиент с помощью Color.FromKnownColor с цветами ControlLight и ControlDark.
  • По возможности сохраните высоту заголовка до 150 пикселей. Обычно высота 100 или 120 будет выполняться. Как правило, убедитесь, что она меньше 1/4 высоты всей формы.
  • Если вы хотите добавить редактирование на месте для сведений, отображаемых в заголовке выше, динамически замените LinkLabel текстовым полем и переключите их еще раз после редактирования.
  • Если у вас есть метка заголовка с шрифтом более 10 пт в размере, используйте Arial или Franklin Готический средний. MS Sans Serif будет выглядеть слишком сильно и непрофессионально. Франклин Готическая среда является рекомендацией в документации по проектированию Windows XP. Для приложений, предназначенных для Windows Vista, используйте шрифт пользовательского интерфейса Segoe, который является системным шрифтом по умолчанию.

Использование настраиваемых полей сообщений

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

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

Microsoft платформа .NET Framework упрощает реализацию пользовательских диалогов. Просто назначив несколько свойств в пользовательской форме диалогового окна или с одной строкой кода, форма может работать так же, как стандартное поле сообщения. В событии нажатия кнопки задайте для свойства DialogResult свойство DialogResult.Ok или DialogResult.Cancel. Используйте метод ShowDialog([OwnerForm]) из родительской формы. Этот метод возвращает значение DialogResult .

Вы можете использовать все элементы DialogResult . Эти же параметры используются стандартным методом MessageBox.Show .

Кроме того, можно просто задать для свойства AcceptButton диалогового окна значение btnOK, а свойство CancelButton — btnCancel. Это автоматически сопоставляет ключи ВВОД и ESC с соответствующими событиями click кнопок btnOK и btnCancel.

Ниже приведены некоторые советы по созданию пользовательских диалогов:

  • Для сложных тем укажите ссылки на локальную или онлайн-справку по LinkLabel с указанием "Узнать больше" под соответствующей текстовой меткой.
  • Вместо кнопок "Да//отмены", используйте тексты, которые четко указать результат нажатия кнопки, например "Сохранить файл и выход", "Выход без сохранения" и "Не выход". Тем не менее, придерживайтесь стандартных да/нет, /Отмена и такие стандартные кнопки всякий раз, когда это возможно. Знакомство делает для большой производительности.
  • Удерживайте 50 пикселей на левой стороне (или правой стороне в зависимости от параметров целевого языка и региональных параметров) и добавьте значок, представляющий сценарий для диалогового окна. Если это диалоговое окно сведений, можно использовать значок "i", используемый стандартными полями сообщений; Если это диалоговое окно безопасности, можно использовать значок блокировки или значок ключа. Visual Studio 2005 поставляется с большим качеством графики.
  • Всегда убедитесь, что вы обеспечиваете правильную навигацию по клавиатуре для этих кнопок— пользователи используют сочетания клавиш для окон сообщений (например, O for Ok, Y for Yes, C for Cancel и т. д.) в значительной степени. Они, безусловно, нашли бы раздражает, если пользовательское диалоговое окно не использовало их.

Включение альтернативных команд

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

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

Аналогичным образом мы используем визуальные элементы управления для ввода текста или числовых данных. Например, ползунки используются для указания целых чисел, а элементы управления "Календарь" используются для ввода дат. Иногда это может быть удобнее просто вводить путем ввода. Это часто может сделать разницу для пользователя, если вы добавляете элемент управления "Числовой вверх вниз", связанный с ползунком, или используете элемент управления DateTimePicker вместо элемента управления Calendar.

Обработка критических действий

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

снимок экрана диалогового окна критического действия.

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

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

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

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

RadioButtons или ComboBoxes?

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

Рассмотрим реальный пример жизни. Корпорация Майкрософт недавно выпустила предварительную версию графического приложения, конструктор графики выражений (прежнее название — "Акрил"). У меня было около 20 графических объектов, которым мне пришлось назначить определенное свойство отдельно в этом приложении. Это был мрачный процесс. Для этого мне пришлось выбрать объект, нажать кнопку для создания окна параметров и задать параметры. В одном из таких вариантов два варианта должны быть выбраны из ComboBox, как можно увидеть на следующем снимке экрана.

Снимок экрана диалогового окна текстуры фрейминга для графического конструктора выражений.

Если нужно удалить список ComboBox и выбрать второй элемент (только из 2 элементов), он может быть действительно раздражающим. То, что мы обычно не понимаем, это время, необходимое для отображения раскрывающегося списка. Это может тратить много времени и может быть разочарован. Это можно легко решить, поместив в GroupBox с двумя RadioButtons, особенно если доступно так много места. У меня возникли аналогичные проблемы в таких приложениях, как CorelDRAW, Microsoft Access и другие.

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

Иногда лучше использовать RadioButtons, особенно если у вас есть 4 варианта или меньше.

Никогда не нарушайте работу пользователя!

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

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

снимок экрана всплывающего окна.

Окна toast (см. рисунок 10), известные клиентами обмена мгновенными сообщениями, такими как MSN Messenger, являются отличным решением для информирования пользователя о чем-то без раздражения или нарушения его рабочего потока. Существует отличная статья Билла Вагнера о создании тост-окон. Это хорошая политика (и манеры), чтобы не беспокоить каких-либо других приложений о том, как это сделать. Препятствия для таких окон могут быть раздражающими и непродуктивными. Одним из решений является использование ToastSemaphore Mutex , предоставляемого операционной системой, чтобы избежать конфликтов.

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

Предоставление состояния хода выполнения

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

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

снимок экрана диалогового окна индикатора выполнения.

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

Другой метод, который становится популярным, является фиксированным окном toast, которое отображает ход выполнения. Microsoft AntiSpyware downloader/updater или Norton Anti Virus e-mail scanning toasts являются хорошими примерами этого. Конечно, это следует использовать только для асинхронных процессов. В противном случае пользователь может чувствовать себя неуясным. Такие окна лучше всего используются для фоновой обработки, например загрузки обновления или выполнения запланированной задачи, и никогда не следует устанавливать значение Always on top.

Упрощение сложных шагов с помощью мастеров

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

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

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

Тон текста правильно

В руководстве по взаимодействию с пользователем Windows очень важно было сделать следующее: "Тон текста". Это впечатление и чувство, заданное текстом в приложении. Это может быть что-либо из простой подсказки до элемента управления меткой инструкции.

Ранее мы обсудили изменение текста в параметре веб-камеры в MSN Messenger. Это называется правильным текстовым тоном. При работе с не техническими или новичками, получение сообщения на разных аспектах.

Если вы напишете "Путь назначения" над текстовым полем в самостоятельном извлечении приложения, технический пользователь может легко знать, что вы вводите что-то подобное "C:\Temp\MyPath". Начинающий пользователь (думаю, "Мама") может так же легко быть замешанным и потребуется ссылаться на руководство, позвонить в службу технической поддержки или хуже - отказаться. Хорошая альтернатива — указать, что нужно сделать пользователю: "Выберите папку, в которой вы хотите разместить эти файлы". Вы даже можете переименовать "Обзор... " кнопка, размещенная рядом с этим текстовым полем, чтобы "Выбрать папку... "

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

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

Несколько советов по написанию текста:

  • Избегайте говорить о пользователе в третьем человеке. Скажите "Вы" вместо "Пользователь".
  • По возможности разумно используйте "Мое имя:" или "Мой адрес электронной почты:", а не "Имя:" или "Электронная почта:"
  • При предоставлении нескольких параметров напишите текст с точки зрения пользователя. Например, если у вас есть два radioButton под меткой, например "Выбрать разрешение на [имя пользователя] в этой сети" выше двух RadioButtons, например "Разрешить" и "Запретить", замените текст RadioButton на "Я хочу разрешить [имя пользователя]" и "Я хочу запретить [имя пользователя]".
  • Подчеркивание текста только в том случае, если оно используется для ссылок. Он путает пользователя, если подчеркнутый текст не является ссылкой.
  • Обратите внимание на важную информацию с полужирной меткой, но используйте ее тщательно. Слишком много полужирного текста запутано и снижает общее влияние формы.
  • При написании текста для флажка убедитесь, что легко знать, что произойдет, когда он выбран и когда он не выбран или снят. Рекомендуется написать текст непосредственно в результате выбора флажка. Например, напишите "Отправить мне полезную информацию от ваших партнеров" вместо "Не отправлять мне полезную информацию от ваших партнеров". Хотя я могу представить себе многих маркетинговых людей, спорящих об этом конкретном примере, я уверен, что вы знаете, что я имею в виду.
  • Если у вас есть элемент управления , похожий на кнопку (обычно RadioButton с внешним видом кнопки команды), который управляет включенным или отключенным, убедитесь, что он правильно помечен. Если процесс включен, напишите "Включено" вместо "Включить" или "Отключить". Если запись включена, отображается текущее состояние. Если кнопка нажимается (включена) и кнопка "Включить", это может быть запутано и проблематично. "Включить" может предложить пользователю щелкнуть его, думая, что процесс не активен.

Иногда ListView лучше

Часто мы придерживаемся DataGrid или ListBox или даже ComboBox для задач выбора, но с Windows XP и более поздних версий Windows с помощью ListView можно предоставить более широкие возможности.

Мелкие точки элемента управления ListView:

  • Ускоряет распознавание элементов с помощью значков и растровых изображений.
  • Отображает дополнительные сведения с представлениями сведений или плиток.
  • В Visual Studio 2005 можно даже иметь группы для дополнительной классификации. Группы охватывают все представления и являются гибкими. Группы также можно использовать для выравнивания представления иерархии (например, TreeView), где есть больше дочерних узлов, чем родительские узлы. Хорошим примером этого является диалоговое окно "Сетевые подключения" в Windows XP при просмотре с параметром "Показать в группах" и представлением, заданным в качестве сведений.
  • Чтобы настроить элемент управления ListView, вручную покрасьте его, задав свойство OwnerDraw и используя события DrawItem и DrawSubItem.
  • Поддерживает быстрое редактирование элементов ListView на месте.
  • Легко поддерживает переупорядочение вручную.
  • Позволяет пользователям выбирать представление (большие значки, небольшие значки, список и т. д.) они наиболее удобны.

Упрощение навигации с помощью элементов управления и боковой панели

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

Если вы переходите к навигации на основе иерархии с помощью TreeViews или другой аналогично сложной навигации, хорошая программа для пользователя будет элементом управления навигации на основе иерархии. Хотя Visual Studio еще не предоставляет встроенный элемент управления для этого, ознакомьтесь с разделом "Создание элемента управления "Панель" для получения сведений о создании самостоятельно. Элемент управления навигации упрощает поиск текущего расположения в отношении иерархии.

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

Использование довольно графики

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

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

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

Для небольших графиков всегда можно использовать значки и растровые изображения, которые отправляются с Помощью Visual Studio 2005. (Графики, поставляемые с предыдущими версиями, не рекомендуется!)

Предоставление измененных форм, когда это возможно

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

Если окно имеет дело с списками любого рода , особенно ListViews, это становится еще более важным. Изменение размера позволяет пользователю одновременно просмотреть больше данных.

Например, у нас есть приложение, в котором пользователь должен выбрать изображение из большой коллекции. Открытое диалоговое окно позволяет выбрать представление эскизов, но диалоговое окно имеет фиксированный размер, а в списке эскизов отображается только 4 эскиза за раз. Если в коллекции есть сотни изображений, прокрутка и просмотр ( повторяющаяся задача) может быть довольно утомительной и снижением эффективности. Если диалоговое окно доступно для изменения размера, пользователь может сделать его максимально удобным или по крайней мере таким же большим, как и экран, и быстро завершить задачу. Если в списке есть горизонтальное прокрутка( например, подробное представление ListView или DataGrid), это еще более утомительно! Изменения размера окон очень полезны в такой ситуации.

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

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

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

Если у вас есть дополнительные функциональные возможности и вы хотите ненавязчиво предоставить его пользователю, нет места, как область задач. Вы также можете сделать области задач "Автоматическое скрытие" или свернуть, как окна инструментов Visual Studio.

Выбор уведомления

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

Знакомый пример этого — диалоговое окно "Поиск Visual Studio". При поиске или замене текста в Visual Studio отображается поле сообщения с указанием результатов. Но вы также можете отключить это поле сообщения. Это может быть действительно раздражает, если вам нужно нажать клавишу ВВОД или ОК каждый раз, когда вы ищете.

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

Укажите подсказки!

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

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

Не забывайте о маленьких вещах

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

Эти виды "маленьких вещей" являются ядром общего впечатления. Пользовательский интерфейс приложения и ПОЛЬЗОВАТЕЛЬСКИЙ интерфейс — это то, что пользователи будут судить по вашему приложению по крайней мере сначала. Если они видят очевидные ошибки в пользовательском интерфейсе, они могут понять, что ваше приложение будет менее мощным и эффективным.

Заключение

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

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