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

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

У меня есть некоторые конкретные проблемы, над которыми я пытаюсь работать, и буду благодарен за понимание или ресурсы.

Местоположение сообщения об ошибке

Когда у вас есть живая форма проверки, где должно появиться сообщение об ошибке (или успехе) относительно элемента формы?

Некоторые параметры:


Справа от входа

скачать источник bmml - каркасы созданный с помощью макетов Balsamiq


Справа от метки

mockup

скачать источник bmml


Над меткой

mockup

скачать источник bmml


Ниже метки

mockup

скачать источник bmml


Ниже ввода

mockup

скачать источник bmml


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

  • Как отображаются ошибки для радио или групп флажков?
  • Насколько широко распространено сообщение об ошибке?
  • Является ли сообщение об ошибке многострочным?

Видимость сообщения об ошибках

Помимо местоположения, меня также интересует, как видимость сообщения об ошибке влияет на его удобство использования. Это имеет значение или это строго эстетическое решение? Рассмотрим следующие 3 варианта:

mockup

скачать источник bmml

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

  • Где должна быть ошибка в отношении ввода и метки?
  • Как сам дизайн и видимость сообщения об ошибке влияют на его удобство использования?

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

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

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

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

149 голосов | спросил Virtuosi Media 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 27 Sep 2012 03:53:50 +0400 2012, 03:53:50

19 ответов


60

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

Выделение поля красным также полезно, но не всегда возможно. Пример использования ниже.

mockup

скачать источник bmml - Wireframes созданный с помощью макетов Balsamiq

mockup

скачать источник bmml

mockup

скачать источник bmml

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


«Инлайн-проверка и проверка событий» на этой странице кажется идеальным: http://semantic-ui.com/modules/form.html

ответил Fresheyeball 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 27 Sep 2012 04:52:49 +0400 2012, 04:52:49
41

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

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

  1. индикатор изменяется на «успех», например. зеленый круг + галочка или «ошибка» (например, красный круг + восклицательный знак)

  2. Если произошла ошибка, поле выделено

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

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

введите описание изображения здесь>> </p>

<p> Пользователь не любит мысленно возвращаться в форму. Он обрабатывается по полю, пользователь фокусируется на нем по полю и проходит контрольный список. Указав ошибки, как они происходят, мы поддерживаем этот режим и не заставляем пользователя вернуться «позже». Это перерыв в потоке пользователя и раздражение, чтобы нажать «отправить», а затем «заблокировать» и «отправить назад». Это гораздо более гладкий опыт, если проблемы просто подсвечиваются и, следовательно, могут быть исправлены, поскольку они происходят. </p></body></html>

ответил Christian 1 +04002012-10-01T14:10:01+04:00312012bEurope/MoscowMon, 01 Oct 2012 14:10:01 +0400 2012, 14:10:01
30

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

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

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

Наконец, есть дополнительный маршрут, который вы, вероятно, должны предпринять для сообщений об ошибках:

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

Большая часть этой информации содержится в статье WebAIM: полезная и доступная проверка формы и восстановление ошибок

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


mockup

скачать источник bmml - Wireframes созданный с помощью макетов Balsamiq

ответил JonW 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 27 Sep 2012 12:30:51 +0400 2012, 12:30:51
9

Существует старый (2007) белый документ, представленный Human Factors International , который содержит некоторые данные об ошибках. Вывод, с которым они пришли, заключался в следующем:

  

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

     

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

     
  1. Представьте ошибки после этого, встроенные в форму, все сразу
  2.   
  3. Представьте ошибки после этого, встроенные в форму, один за другим
  4.   
  5. Представьте ошибки после этого, в диалогах, по очереди
  6.   

Очевидно, мы больше не будем делать номер 3. Белый документ называется «Что мы узнали: оглядываясь на 2007 год». Вы можете скачать его со своего сайта после заполнения формы . :)

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

ответил Julia D 5 +04002012-10-05T22:00:38+04:00312012bEurope/MoscowFri, 05 Oct 2012 22:00:38 +0400 2012, 22:00:38
4

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

ответил Rutvij Kotecha 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 29 Sep 2012 19:12:05 +0400 2012, 19:12:05
4

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

Я специально рассматриваю вопрос «Когда у вас есть живая форма проверки, где должно появиться сообщение об ошибке (или успехе) относительно элемента формы?»

Что, если мы покажем сообщение вместо самого ярлыка, что-то вроде

введите описание изображения здесь>> </p>

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

<p> Для этого подхода к работе вы можете тщательно изложить свои сообщения, чтобы полностью передать то, что пользователь должен делать в наименее возможных словах. Если сообщения длинны, вы можете привязать их к длине полей. </p></body></html>

ответил roni 16 AMpWed, 16 Apr 2014 11:17:41 +040017Wednesday 2014, 11:17:41
3

Поскольку вопрос касается результатов реальных исследований, вот ссылка на 2009 изучение различных вариаций валидационных сообщений Люком Вроблевским (автор книги «Заполнить бланки»).

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

  

[ON BLUR] МЕТОД ПОМОГАЕТ ПОЛЬЗОВАТЕЛЯМ ЗАПОЛНИТЬ ФОРМЫ БОЛЬШЕ БЫСТРО Когда мы использовали   метод «по-разному» ..., участники   заполнили форму на семь-десять секунд быстрее, чем когда мы использовали   (по нажатию клавиши)) и «до и во время» соответственно.

Что касается положения сообщения об ошибке, исследование показывает, что

  

НЕ СДЕЛАЙТЕ ПРОСМОТРЕТЬ УСПЕШНЫЕ СООБЩЕНИЯ, ПРЕДУСМОТРЕННЫЕ ВНЕШНЕЙ ФОРМЫ ПОЛЯ   Отображение проверки внутри полей формы не удалось выполнить   существенная выгода. Позиционирование этих сообщений   Васа €»necessarilyâ €» непоследовательный. (Хотя можно сделать валидацию   сообщения появляются внутри полей формы, гораздо труднее   отображать их в стандартных раскрывающихся списках, поэтому мы отображали их   вне этих элементов.) Валидация в поле уже не была   заметны, чем сообщения, отображаемые вне полей.

2- Что касается видимости сообщения (цвета и т. д.), здесь

ответил Son Do Lenh 10 J0000006Europe/Moscow 2014, 22:26:07
2

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

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

Теперь, касаясь проблемы с радиокнопками, я бы сказал, что если вам нужно такое сообщение об ошибке для переключателя, это означает, что переключатель не является правильным вариантом дизайна из первых рук: действительно, по существу, , ДОЛЖЕН иметь и ДОЛЖЕН иметь ТОЛЬКО по умолчанию одну единственную опцию. Это означает, что радиокнопка должна всегда показывать выбранную по умолчанию опцию, независимо от того, является ли она «ничем». В любом другом случае вам следует рассмотреть возможность использования любого другого варианта дизайна, который соответствует вашим потребностям (например: флажки, если можно выбрать несколько параметров или выпадающее меню или что-то еще).

ответил Ivan 1 +04002012-10-01T13:24:16+04:00312012bEurope/MoscowMon, 01 Oct 2012 13:24:16 +0400 2012, 13:24:16
2

После прочтения Дизайн веб-формы: заполнение бланков и исследование об этом в Интернете. Я узнал, что лучшие из них находятся под вводом или справа от ввода.

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

ответил Igor-G 4 +04002012-10-04T15:05:06+04:00312012bEurope/MoscowThu, 04 Oct 2012 15:05:06 +0400 2012, 15:05:06
2

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

Итак ... взаимодействие с пользователями Windows Руководство по существу выбирает звездочку слева от метки и всплывающей подсказки с сообщением :

mockup

скачать источник bmml - каркасы созданный с помощью макетов Balsamiq

В руководящих принципах также содержатся некоторые проницательные моменты, которые я кратко изложил ниже:

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

Интересно, что в Руководства по человеческому интерфейсу Apple по этой теме, но ниже приведено резюме соответствующих пунктов, которые я нашел:

  • Проверить ранний ввод
  • Избегайте проверки ввода после каждого нажатия клавиши. Частая проверка является раздражающей.

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

ответил Scott Willeke 11 +04002012-10-11T03:51:33+04:00312012bEurope/MoscowThu, 11 Oct 2012 03:51:33 +0400 2012, 03:51:33
2

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

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

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

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

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

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

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

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

ответил GlenFinch 5 PMpFri, 05 Apr 2013 13:49:22 +040049Friday 2013, 13:49:22
1

К сожалению, кажется, что не существует «стандартного» способа отображения ошибки для a из, что было исходным вопросом.

Я попытался найти более подробный ответ, но я думаю, что нет определенного решения, потому что существует так много разных стилей форм. Формы, просматриваемые на рабочем столе, как правило, имеют больше места для текста ошибки, чем форма на мобильном устройстве. В последнее время вы должны даже подумать о том, какую операционную систему вы сейчас разрабатываете, так как современный стиль Windows 8 (формально Metro) имеет специальные правила стиля для IE. Добавьте к тому, что каждый современный браузер имеет свой собственный стиль для проверки формы HTML5, и стандартизация этого становится беспорядком.

Больше всего я мог найти набор рекомендаций от Якоба Нильсена ( http: //www. useit.com/alertbox/20010624.html ). Эти рекомендации очень широкие, при этом единственным явным правилом является то, что вы можете не только полагаться на цвет (поворот текста для красного поля), потому что это может затруднить чтение пользователей с ограниченными возможностями. Следящие слепые пользователи или те, кто использует экранные считыватели, не смогут отличить текст.

Это единственная оговорка, которую я имею с решением выноски, также размещенным здесь. Могут ли пользователи с ограниченными возможностями читать это?

Решением может быть либо адаптация стиля, который используется большинством ваших целевых пользователей (Microsoft, Google или Apple), и с этим.

ответил Kevin G 5 +04002012-10-05T20:01:34+04:00312012bEurope/MoscowFri, 05 Oct 2012 20:01:34 +0400 2012, 20:01:34
1

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

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

введите описание изображения здесь>> </p></body></html>

ответил Rajesh R. Nair 25 WedEurope/Moscow2013-12-25T16:11:09+04:00Europe/Moscow12bEurope/MoscowWed, 25 Dec 2013 16:11:09 +0400 2013, 16:11:09
1

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

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

ответил Relvid 16 AMpWed, 16 Apr 2014 08:48:37 +040048Wednesday 2014, 08:48:37
0

Я согласен с другими, что должно быть резюме. Будь то конкретная учетная запись или «Что-то пошло не так». Просмотрите все выделенные записи, внесите необходимые изменения и повторно отправьте форму. Спасибо.

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

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

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

  • Отмечено с текстом ошибки, который выглядит иначе, чем цвет. Курсив или полужирный с цветом лучше, чем просто цвет. Уникальный цвет (с красным стандартом) хорош, но все мы знаем о пользователях с цветным слепым, не так ли?
  • Выделяются из других полей вне текста и текста. Было бы очень здорово, если бы все поля «ok» были немного выделены, так что можно было видеть, что те, которые нуждаются в редактировании, выделяются более резко. Однако, если вы хотите отредактировать одно из этих полей «ok», щелчок должен «открыть» их для «яркого» редактирования.
ответил Tom Quick 1 +04002012-10-01T09:08:52+04:00312012bEurope/MoscowMon, 01 Oct 2012 09:08:52 +0400 2012, 09:08:52
0

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

Я столкнулся с этой проблемой на работе и хотел найти способ, который был бы удобным и доступным. Я нашел этот пост в блоге http: //www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/, которые очень помогли. Будучи тем, что я работаю над разработкой приложений для Университета, такие вещи очень важны.

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

В примере используется jQuery и плагин validate.

Подводя итог:

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

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

ответил zxbEPREF 1 +04002012-10-01T21:00:49+04:00312012bEurope/MoscowMon, 01 Oct 2012 21:00:49 +0400 2012, 21:00:49
0

Всегда лучше всего

  1. Показать встроенные сообщения об ошибках
  2. И установите фокус на первое поле мандата, оставленное пустым, или поле с недопустимыми данными после отправки формы.

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

  1. Фокусировка поля Красный и отображение встроенного сообщения об ошибке

В случае проверки на стороне сервера, например. где js отключен -

  1. Показывать встроенное сообщение об ошибке с фокусом на пустое поле или поле с недопустимыми данными

Обычная практика -

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

Тем не менее традиционный способ маркировки полей мандата с помощью «*» является лучшим

ответил Satish Kumar Nadarajan 2 +04002012-10-02T23:26:50+04:00312012bEurope/MoscowTue, 02 Oct 2012 23:26:50 +0400 2012, 23:26:50
0

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

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

ответил Jay 9 +03002015-10-09T03:49:53+03:00312015bEurope/MoscowFri, 09 Oct 2015 03:49:53 +0300 2015, 03:49:53
0

Я думаю, что способ отображения сообщений об ошибках в Facebook наиболее эффективен и удобен для пользователя. Проверьте скриншот. Этот не требует лишнего места. Пользователь получает то, что неправильно, а также знать более подробно, он может просто навести курсор на поле, чтобы узнать, почему поле является обязательным. введите описание изображения здесь>> </a> </p></body></html>

ответил Parag Bandewar 16 SatEurope/Moscow2017-12-16T09:48:18+03:00Europe/Moscow12bEurope/MoscowSat, 16 Dec 2017 09:48:18 +0300 2017, 09:48:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132