Лучшие практики и принципы разработки графического интерфейса пользователя [закрыты]
https://stackoverflow.com/questions/90813
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Каков ваш наилучший практичный дизайн или принцип использования пользовательского интерфейса?
Пожалуйста, присылайте те практики, которые, по вашему мнению, действительно делают вещи действительно полезными - несмотря ни на что, - если это работает для ваших пользователей, поделитесь этим!
Сводка/ Сопоставление
Принципы
- ПОЦЕЛУЙ.
- Будьте ясны и конкретны в том, чего достигнет тот или иной вариант:например, используйте глаголы, указывающие на действие, которое последует за выбором (см.:Импл.1).
- Используйте очевидные действия по умолчанию, соответствующие тому, что нужно пользователю / чего он хочет достичь.
- Приведите внешний вид и поведение пользовательского интерфейса в соответствие со средой / процессом / аудиторией:автономное приложение, веб-страница, портативное, научный анализ, флеш-игра, для профессионалов / детей, ...
- Сократите время обучения нового пользователя.
- Вместо отключения или скрытия параметров рассмотрите возможность предоставления полезного сообщения, в котором у пользователя могут быть альтернативы, но только там, где эти альтернативы существуют.Если альтернативы недоступны, лучше отключить опцию, которая затем визуально указывает, что опция недоступна - не скрывайте недоступные опции, а объясните во всплывающем окне при наведении курсора мыши, почему она отключена.
- Оставайтесь последовательными и соблюдайте практику и размещение элементов управления, как это реализовано в широко используемых успешных приложениях.
- Оправдайте ожидания пользователя и позвольте вашей программе вести себя в соответствии с этими ожиданиями.
- Придерживайтесь словарного запаса и знаний пользователя и не используйте терминологию программиста / реализации.
- Следуйте основным принципам проектирования:контраст (очевидность), повторяемость (последовательность), выравнивание (внешний вид) и близость (группировка).
Реализация
- (Смотрите ответ Пейни) "Попробуйте использовать глаголы в своих диалоговых окнах".
- Разрешить / реализовать отмену и повтор.
Ссылки
- Рекомендации по работе с Windows Vista [http://msdn.microsoft.com/en-us/library/aa511258.aspx ]
- Голландские веб-сайты - рекомендации "Drempelvrij" [http://www.drempelvrij.nl/richtlijnen]
- Рекомендации по обеспечению доступности веб-контента (WCAG 1.0) [http://www.w3.org/TR/WCAG10 /]
- Консистенция [http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746 ]
- Не заставляй меня Думать [http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pdbbssr_1?ie=UTF8&s=books&qid=1221726383&sr=8-1]
- Будьте мощны и просты [http://msdn.microsoft.com/en-us/library/aa511332.aspx ]
- Законы гештальт - дизайна [http://www.squidoo.com/gestaltlaws ]
Решение
Старайтесь использовать глаголы в своих диалоговых окнах.
Это означает использовать
вместо того, чтобы
Другие советы
Я тестирую свой графический интерфейс на примере своей бабушки.
Следуйте основным принципам проектирования
- Contrast - Создавайте вещи, которые отличаются друг от друга посмотри другой
- Rэпитет - Повторите тот же стиль на экране и для других экранов.
- Aвыравнивание - Выровняйте элементы экрана вверх!Да, это включает текст, изображения, элементы управления и метки.
- Proximity - Группируйте связанные элементы вместе.Набор полей ввода для ввода адреса должен быть сгруппирован вместе и отличаться от группы полей ввода для ввода информации о кредитной карте.Это основное Законы Гештальт-дизайна.
Никогда спросите: "Вы уверены?".Просто разрешите неограниченную и надежную отмену / повтор.
Попробуйте подумать о том, чего хочет достичь ваш пользователь, а не о том, каковы требования.
Пользователь войдет в вашу систему и будет использовать ее для достижения поставленной цели.Когда вы открываете calc, вам нужно производить простые быстрые вычисления в 90% случаев, поэтому по умолчанию он настроен на простой режим.
Поэтому не думайте о том, что должно делать приложение, а подумайте о пользователе, который будет это делать, возможно, ему будет скучно, и попытайтесь разработать дизайн, исходя из его намерений, постарайтесь облегчить ему жизнь.
Если вы делаете что-либо для Интернета или любого программного приложения, ориентированного на внешний интерфейс, если уж на то пошло, вы действительно обязаны прочитать это ради себя...
Панировочные сухари в webapps:
Скажите -> -> Пользователю ->, где -> Она -> Находится в системе
Это довольно сложно сделать в "динамических" системах с несколькими путями к одним и тем же данным, но это часто помогает ориентироваться в системе.
Я стараюсь адаптироваться к окружающей среде.
При разработке приложения для Windows я использую Рекомендации по работе с Windows Vista но когда я разрабатываю веб-приложение, я использую соответствующие рекомендации, поскольку я разрабатываю голландские веб-сайты, я использую Руководящие принципы "Drempelvrij" которые основаны на Рекомендации по обеспечению доступности веб-контента (WCAG 1.0) консорциумом Всемирной паутины (W3C).
Причина, по которой я делаю это, заключается в том, чтобы сократить время обучения нового пользователя.
Я бы рекомендовал получить хорошее представление о дизайне графического интерфейса пользователя, прочитав эту книгу Дизайн повседневных вещей.Хотя основным материалом для печати является комментарий от Джоэл Спольский:Когда поведение приложения отличается от того, что ожидает пользователь, у вас возникает проблема с вашим графическим пользовательским интерфейсом.
Лучший пример - это когда кто-то меняет местами ОК и Отмена кнопка на некоторых веб-сайтах.Пользователь ожидает, что ОК кнопка должна находиться слева, а Отмена кнопка должна быть справа.Короче говоря, когда поведение приложения отличается от того, что ожидает пользователь, у вас возникает проблема с дизайном пользовательского интерфейса.
Хотя лучший совет, независимо от того, какому дизайну или шаблону проектирования вы следуете, заключается в том, чтобы дизайн и условные обозначения были согласованы во всем приложении.
Избегайте просить пользователя делать выбор всякий раз, когда вы можете (т. е.не создавайте форк с диалогом настройки!)
Для каждого варианта и каждого окна сообщения спросите себя:могу ли я вместо этого придумать какое-нибудь разумное поведение по умолчанию, которое
- имеет смысл?
- не мешает пользователю?
- достаточно ли легко понять, что пользователю ничего не стоит, что я навязываю ему это?
В качестве примера я могу использовать свой карманный компьютер Palm:настройки действительно минималистичны, и я этим вполне доволен.Базовые приложения достаточно хорошо разработаны, чтобы я мог просто использовать их, не чувствуя необходимости в настройке.Хорошо, есть некоторые вещи, которые я не могу сделать, и на самом деле мне как бы пришлось приспосабливаться к инструменту (а не наоборот), но, в конце концов, это действительно облегчает мою жизнь.
Этот веб-сайт - еще один пример:вы ничего не можете настроить, и все же я нахожу это действительно приятным в использовании.
Разумные значения по умолчанию может быть трудно определить, и простые тесты удобства использования могут дать множество подсказок, которые помогут вам в этом.
Покажите интерфейс выборке пользователей.Попросите их выполнить типичное задание.Следите за их ошибками.Прислушайтесь к их комментариям.Внесите изменения и повторите.
Дизайн повседневных вещей - Дональд Норман
Канон знаний в области дизайна и основа многих курсов HCI в университетах по всему миру.Вы не создадите отличный графический интерфейс за пять минут с помощью нескольких комментариев с веб-форума, но некоторые принципы направят ваше мышление в нужное русло.
--
МС
При создании сообщений об ошибках сделайте так, чтобы сообщение об ошибке было ответы на эти 3 вопроса (в таком порядке):
Что случилось?
Почему это произошло?
Что можно с этим сделать?
Это из "Руководства по человеческому интерфейсу:Рабочий стол Apple Интерфейс" (1987, ISBN 0-201-17753-6), но его можно использовать для любого сообщения об ошибке в любом месте.Существует обновленная версия для Mac OS X.Страница Microsoft Сообщения пользовательского интерфейса говорит то же самое:"...в случае появления сообщения об ошибке вы должны указать проблему, причину и действие пользователя для устранения проблемы. "
Также включите любую информацию, которая известна программе, а не просто какую-то фиксированную строку.Например.для части сообщения об ошибке "Почему это произошло" используйте "Raw spectrum file L: efDataForMascotParser ripleEncoding\Q1LCMS190203_01Doub leArg.wiff не существует" вместо просто "Файл не существует".
Сравните это с печально известным сообщением об ошибке:"Произошла ошибка "..
(Украдено у Джоэла :o) )
Не отключайте / удаляйте параметры - скорее выдавайте полезное сообщение, когда пользователь нажимает / выбирает его.
Как отметил сегодня мой профессор по структуре данных:Дайте инструкции о том, как работает ваша программа, обычному пользователю.Мы, программисты, часто думаем, что в наших программах все довольно логично, но обычный пользователь, вероятно, не будет знать, что делать.
Используйте сдержанные / простые анимированные элементы для создания плавных переходов от одного раздела к другому.Это помогает пользователю создать мысленную карту навигации / структуры.
Используйте короткие (по возможности из одного слова) заголовки на кнопках, которые четко описывают суть действия.
Используйте семантическое масштабирование там, где это возможно (хорошим примером является то, как работает масштабирование на картах Google / Bing, где при фокусировке на области видно больше информации).
Создайте по крайней мере два способа навигации:Вертикальный и горизонтальный.Вертикальный при перемещении между различными разделами и горизонтальный при перемещении по содержимому раздела или подраздела.
Всегда держите основные узлы параметров вашей структуры видимыми (там, где это позволяют размер экрана и тип устройства).
Когда вы углубляетесь в структуру, всегда сохраняйте видимую подсказку (т. е.например, в виде пути), указывающего, где вы находитесь.
Скрывайте элементы, когда вы хотите, чтобы пользователь сосредоточился на данных (например, при чтении статьи или просмотре проекта).- однако остерегайтесь пунктов №5 и №4.
Да, и наймите дизайнера / научитесь дизайнерским навыкам.:)
Что касается графических интерфейсов, стандарты в некотором роде зависят от платформы.Например.При разработке графического интерфейса в Eclipse это Ссылка обеспечивает достойное руководство.
Я прочитал большую часть из вышеперечисленного и одну вещь, которую я не вижу упомянутой:
Если предполагается, что пользователи будут пользоваться интерфейсом ОДИН раз, то неплохо показывать только то, что им нужно использовать, если это возможно.
Если пользовательский интерфейс будет использоваться одним и тем же пользователем неоднократно, но, возможно, не очень часто, лучше отключить элементы управления, чем скрывать их:изменение пользовательского интерфейса и скрытые функции, которые не видны (или не запоминаются) случайным пользователем, расстраивают его.
Если пользовательский интерфейс будет использоваться ОЧЕНЬ РЕГУЛЯРНО одним и тем же пользователем (и текучесть кадров в работе невелика, т. е.не так много новых пользователей постоянно выходят в Сеть) отключение элементов управления абсолютно полезно, и пользователь привыкнет к причинам, по которым что-то происходит, но предотвращение случайного использования элементов управления в неподходящих контекстах ценится и предотвращает ошибки.
Это просто мое мнение, но все это восходит к пониманию вашего профиля пользователя, а не только того, что может повлечь за собой один сеанс пользователя.
