Сообщить об опечатке » Техподдержка Prihod.ru

*Подключить плагин можно в разделе консоли вашего сайта Плагины.

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

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

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

Для работы плагина нужно настроить 2 важные вещи:

1. Куда будут приходить сообщения об ошибке.
2. Рассказать вашим пользователям, что на вашем сайте есть возможность сообщить об опечатке и как этим пользоваться.

1. Добавление e-mail адреса, на который будет отправляться уведомление об опечатке

Для того, чтобы добавить е-мэйл получателя зайдите в раздел консоли «Настройки» — «Сообщение об опечатке».

Введите в поле е-мэйл, на который будут отправляться уведомления об опечатках:

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

2. Информирование посетителей о том, каким образом они могут сообщить об опечатке

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

Заметили опечатку?
Выделите текст и нажмите CTRL+ENTER.

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

Зайдите в раздел консоли «Внешний вид» — «Виджеты», перетащите в нужную область виджет «Сообщение об опечатке».

Настройки виджета:

Заголовок — введите заголовок виджета (поле можно оставить пустым).

Описание сверху — добавьте описание, которое будет выводиться перед ссылкой или кнопкой. В описании можно использовать следующие html-теги форматирования текста: b,i,u,li,ul,h2,h3,h4,h5,h5,br,center,small.

Например, в этом поле можно вставить информационный текст «Заметили ошибку?
Выделите текст и нажмите CTRL+ENTER или ссылку (картинку, кнопку) ниже.»

Тип — выберите тип ссылки, при нажатии на которую будет срабатывать Ctrl+Enter.

• Ссылка — простая текстовая ссылка.
• Изображение — можно будет вывести любую картинку.
• Кнопка — будет отображаться кнопка с заданным цветом и текстом.

Параметр — Для типа «Ссылка» введите текст (например, «сообщите об ошибке»). Для типа «Изображение» введите путь к изображению (например: http://site.ru/image.jpg). Для типа «Кнопка» введите текст, который будет отображаться на кнопке.

Здесь можно посмотреть где брать ссылку на изображение, загруженное на ваш сайт.

Цвет — в данном поле можно задать цвет ссылки или цвет кнопки (в зависимости от выбранного типа).

Размер — в данном поле можно задать размер текста ссылки на кнопке, а также ширину изображения, если выбрана картинка.

Описание снизу — добавьте описание, которое будет выводиться после ссылки или кнопки. В описании можно использовать следующие теги форматирования текста: b,i,u,li,ul,h2,h3,h4,h5,h5,br,center,small.

Важно! Чтобы верхний текст, кнопка (ссылка, изображение) и нижний текст не сливались в одну массу, используйте тег <br> или просто перенос на новую строку клавишей Enter. В поле «Описание сверху» тег или перенос добавляйте после текста, а в поле «Описание снизу» — перед текстом.

Пример

Виджет с типом «Ссылка»:

На сайте:

Пример отображения виджета с типом «Кнопка»:

Просмотрено (11024) раз

Как посмотреть ошибки в консоли браузера: краткий мануал

Каждый браузер оснащен консольной панелью, с помощью которой разработчики проводят тестирование веб-сайта.  Вкладка Elements содержит всю информацию об инспектируемом HTML-файле: теги, таблицы стилей и т.д. Но в консоли есть и другие разделы, такие как Console, Sources, Network и прочие.

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

Как открыть консоль на разных браузерах

Алгоритм запуска консоли (инспектора) во всех браузерах идентичен. Есть два пути: первый – запуск через специальную клавишу на клавиатуре, второй – через функцию «Посмотреть код страницы/элемента». 

Например, если воспользоваться в Chrome клавишей F12, то откроется дополнительное окно с консолью.

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

В результате перед нами снова отобразится окно, в котором будет открыта главная вкладка с кодом страницы. Подробнее о ней мы еще поговорим, а пока давайте посмотрим, как выполняется запуск консоли в браузере Safari на устройствах Mac.

Первым делом нам потребуется включить меню разработчика – для этого переходим в раздел «Настройки» и открываем подраздел «Продвинутые». Находим пункт «Показать меню «Разработка в строке меню» и отмечаем его галочкой.

Теперь можно запустить консольное окно – достаточно воспользоваться комбинацией клавиш «Cmd+Opt+C».

Как видите, запустить консоль в браузере – дело нескольких секунд. Опция полезна, когда вы верстаете новый сайт, исправляете ошибки, проводите различные тесты. 

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Какие вкладки есть в консоли и за что они отвечают

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

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

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

Если выбрать опцию «Responsive», то слева от страницы отобразится дополнительная линия, которую мы можем тянуть влево или вправо – с помощью нее можно подобрать необходимое разрешение страницы. Также настроить разрешение мы можем и в верхней части окна.

И еще одна опция, которая может быть полезна – изменение расположения консольной панели. Чтобы ей воспользоваться, необходимо в верхней правой части нажать на кнопку в виде троеточия и в строке «Dock side» изменить ориентацию. Доступные положения: справа, слева, снизу, в отдельном окне.

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

Elements

Основной компонент для верстальщиков. Он включает в себя всю информацию об открытой HTML-странице. Здесь мы можем не только посмотреть текущие теги и атрибуты, но и изменить их – в таком случае произойдет автоматическое изменение дизайна на странице. Если ее обновить, все вернется на свои места. Также открыт доступ к просмотру CSS и прочих элементов – для этого в правой части раздела идут вкладки Styles, Computed, Layout, Event Listeners, DOM Breakpoints, Properties и Accessibility.

Console

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

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

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

Sources

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

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

Network

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

Performance

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

Memory

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

Application

Данный раздел позволяет инспектировать и очищать все загруженные ресурсы. Мы можем взаимодействовать с HTML5 Database, Local Storage, Cookies, AppCache и другими элементами.

Основная особенность опции – чистка куки. Если вам необходимо выполнить эту процедуру, то просто откройте в левой части раздел «Cookies» и нажмите справа на значок запрета. Куки для выбранной ссылки будут очищены.

Security

Раздел Security отображает информацию о безопасном протоколе. Если его нет, то будет сообщено, что данная страница является небезопасной. Кроме того, можно получить еще некоторые сведения о:

• проверке сертификата – подтвердил ли сайт свою подлинность TLS;
• tls-соединении – использует ли сайт современные безопасные протоколы;
• безопасности второстепенных источников.

Lighthouse

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

Выявление основных ошибок

При возникновении возможных ошибок мы сразу будем об этом уведомлены во вкладке Console – в ней отобразится информация с красной строкой текста. Рассмотрим самые распространенные ошибки, которые могут возникать в Google Chrome, Safari и Internet Explorer:

1. Uncaught TypeError: Cannot read property. Ошибка возникает в Хроме при вызове метода или чтении свойства для неопределенного объекта.
2. TypeError: ‘undefined’ is not an object (evaluating). Аналогична предыдущей ошибке, но только в Safari.
3. TypeError: null is not an object (evaluating). Возникает в Сафари при вызове метода или чтении свойства для нулевого объекта.
4. (unknown): Script error. Обозначает ошибку скрипта.
5. TypeError: Object doesn’t support property. Встречается в Internet Explorer – возникает при вызове определенного метода.
6. TypeError: ‘undefined’ is not a function. Указывает на неопределенную функцию (в Chrome).
7. Uncaught RangeError: Maximum call stack. Ошибка в Chrome, означающая превышение максимального размера стека.
8. TypeError: Cannot read property ‘length’. Невозможно прочитать свойство.
9. Uncaught TypeError: Cannot set property. Возникает, когда скрипт не может получить доступ к неопределенной переменной.
10. ReferenceError: event is not defined. Обозначает невозможность получения доступа к переменной, не входящей в текущую область.

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

Заключение

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

Изучайте и находите свои применения этому инструменту – он может многое. Удачи!

UX Design: Четыре способа отображения сообщений об ошибках

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

Outline

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

1. Сообщение об ошибке должно быть коротким и осмысленным
2. Расположение сообщения должно быть связано с полем
3. Стиль сообщения должен быть отделен от стиля меток полей и инструкций
4. Стиль поле ошибки должно отличаться от обычного поля

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

Умное размещение меток, инструкции по заполнению полей и дополнительные элементы дизайна могут сделать форму менее сложной и привести к меньшему количеству ошибок (Jarrett, C. and Gaffney, G., 2008). Тем не менее, я видел, что пользователи снова и снова совершают одни и те же ошибки в формах, поскольку эти веб-сайты показывают сообщения об ошибках, которые либо не очень понятны пользователю, либо из-за их размещения пользователи не понимают, к чему относятся сообщения. В этой статье основное внимание уделяется тому, как предоставлять сообщения об ошибках в формах с точки зрения взаимодействия с пользователем.

Сообщение

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

Рисунок 1: Страница регистрации Hotmail — сообщение об ошибке не указывает, как указать год рождения (например, «гггг»)

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

Рисунок 2: Улучшенное сообщение об ошибке, чтобы люди могли понять, какую ошибку они совершили

Размещение

Сообщение должно быть не только кратким и лаконичным, но также должно быть удобно расположено, чтобы связать его с полем. В связи с этим возникает вопрос, где лучше разместить сообщение об ошибке — над, после, слева или справа от поля? Это зависит от типа сообщения об ошибке. Если это ошибка «отсутствует обязательное поле», ее можно поместить вверху, справа или внизу поля.

Рис. 3. Пример сообщения об ошибке «отсутствует обязательное поле» в нижней части соответствующих полей (от eBay)

Рис. 4. Пример сообщений об ошибках «отсутствует обязательное поле» над метками

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

Рис. 5. Сообщение об ошибке входа в Google

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

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

Рис. 7. Отображаемые сообщения об ошибках соответствуют шаблону чтения пользователя

А как насчет длинных форм? По нашему предыдущему опыту мы видели, что если пользователь делает ошибку при заполнении длинной формы, а поле с ошибкой находится ниже сгиба, он запутывается, пытаясь понять, что произошло. Рисунок 8: Пример полной формы (из общего приложения) . Это даст пользователям четкое представление о том, где они допустили ошибки. Однако необходимо убедиться, что эти сообщения об ошибках не перегружают пользователей, как в примере, показанном на рисунке 9..

Рисунок 9. Сообщения об ошибках, показанные вверху и с соответствующими полями (страница регистрации Sainsbury)

Стиль сообщений

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

Стиль поля

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

Рисунок 10: Регистрационная форма WordPress с другим стилем границы поля ошибки

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

Этот конкретный веб-сайт требует, чтобы все пользователи были зарегистрированы до начала процесса покупки. В процессе регистрации пользователь заполнил форму, указав свое имя, имя пользователя и пароль, и отправил ее. Затем была отображена та же форма с сообщением об ошибке: «Пожалуйста, введите новое имя пользователя, состоящее из комбинации буквенно-цифровых символов в диапазоне от 6 до 14 символов. Это должно быть уникальным для всех наших клиентов». Кроме того, поле пароля, в которое она ввела желаемый пароль, стало пустым.

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

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

Что пошло не так?

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

Использование четырех основных правил отображения сообщений об ошибках

Если мы примем эти правила для приведенного выше примера, мы сможем найти несколько решений.

Отображение сообщений об ошибках в формах с метками, расположенными слева:

Например, если мы хотим исправить сообщение об ошибке, в котором говорилось: «Пожалуйста, введите новое имя пользователя со смесью буквенно-цифровых символов в диапазоне от 6 до 14 символов. Оно должно быть уникальным для всех наших клиентов», оно может выглядеть примерно так: «Имя пользователя должно содержать от 6 до 14 символов и содержать как минимум 1 цифру и 1 символ». Используя правила размещения и стиля, мы можем предоставить следующий пример:

Рисунок 11: Пример использования 4-точечных правил отображения сообщений об ошибках

Отображение сообщений об ошибках в соответствии с шаблоном чтения пользователя:

сообщения об ошибках и соответствуют шаблону чтения пользователя:

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

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

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

Nomensa — удостоенное наград агентство UX-дизайна с офисами в Бристоле, Лондоне и Амстердаме.

Если вы хотите, чтобы мы помогли вам с вашими проблемами взаимодействия с пользователем или предоставили вам оценку UX вашего веб-сайта / мобильного приложения, пожалуйста, не стесняйтесь обращаться к нам. Вы можете позвонить нам по телефону +44 (0) 117 929 7333 или отправить эту короткую форму. А пока ознакомьтесь с услугами UX Design, которые мы предлагаем.

Ссылки

• Джарретт К. и Гаффни Г. Формы, которые работают, Проектирование веб-форм для удобства использования, 2008 г.
• Пензо, М., Размещение ярлыков в формах, опубликовано в UX Matters, июль 2006 г.
• Вроблевски, Л., Дизайн форм веб-приложений, январь 2005 г. процесс, мы обеспечиваем общее видение. Наш гибкий подход, основанный на спринте, позволяет нам эффективно создавать прототипы и итерации, а также подкреплять наше мышление пользовательским тестированием.

  Узнайте больше об услугах UX-дизайна

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

  Узнайте больше о прототипировании в UX

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

  Узнайте больше о персонажах

  Заинтересованы в том, чтобы взять нас на борт?
  

  Мы хотели бы обсудить, как мы могли бы улучшить ваш пользовательский опыт.

  Связаться

  Разработка улучшенных сообщений об ошибках UX — Smashing Magazine

  • 18 мин чтения
  • UX,
    Удобство использования,
    Шаблоны проектирования
  • Поделиться в Twitter, LinkedIn

  Об авторе

  Виталий Фридман любит красивый контент и не любит легко сдаваться. Когда он не пишет, он, скорее всего, занимается интерфейсом и UX…
  Больше о
  Виталий ↬

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

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

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

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

  Не все сообщения об ошибках одинаковы

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

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

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

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

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

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

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

  Никогда не полагайтесь только на красный цвет

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

  Простое обычное сообщение об ошибке: красное и полужирное. Как используется на Gov.uk. (Большой предварительный просмотр)

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

  Всегда хорошая идея: добавить значок и толстую вертикальную линию для всего раздела. (Большой предварительный просмотр)

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

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

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

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

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

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

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

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

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

  Никогда не скрывайте ввод пользователя

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

  Встроенное редактирование и проверка в таблицах. Типичный пример. (большой превью)

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

  Когда всплывающая подсказка блокирует содержимое, пример из Carbon Design System.

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

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

  Компонент деталей, детали которого появляются при касании/щелчке. (большой превью)

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

  Больше после прыжка! Продолжить чтение ниже ↓

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

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

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

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

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

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

  В таблицах отображать сообщения об ошибках в строке

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

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

  Сообщения об ошибках могут располагаться в той же строке, что и ошибочное содержимое. Источник: Мир UX-дизайна. (Большое превью)

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

  Если ошибка появляется несколько раз и ее легко объяснить, было бы неплохо показать ее в самом верху страницы. Источник изображения: UX Design World. (Большой предварительный просмотр)

  Не полагайтесь на всплывающие сообщения об ошибках

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

  Мир всплывающих уведомлений. Система дизайна Seb Group. (Большой предварительный просмотр)

  Существует несколько распространенных проблем с удобством использования со всплывающими сообщениями об ошибках:

  • Пользователи часто не имеют возможности полностью прочитать или понять сообщение об ошибке до того, как оно исчезнет, ​​и нет возможности чтобы восстановить его или оставить плавающим.
  • Тост-сообщения обычно появляются по краям экрана и обычно довольно далеко от проблемного ввода, вызвавшего ошибку. Между сообщением об ошибке и входными данными существует значительный разрыв, и редко бывает возможным прочитать сообщение об ошибке и исправить ошибку одновременно.
  • Длинные всплывающие сообщения обычно блокируют большие области контента , на которые может полагаться пользователь, и, возможно, даже ввод, вызвавший ошибку.
  • Всплывающие сообщения должны быть объявлены пользователям программы чтения с экрана , а также должны позволять пользователям переключаться между сообщением об ошибке и ошибочным вводом.
  • С всплывающими уведомлениями нам обычно не хватает места, чтобы предоставить подробную справку с использованием изображений или видео , и нам приходится полагаться на простой текст и ссылки, ведущие на внешние страницы справки, которые обычно открываются в новой вкладке.

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

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

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

  Разрешить пользователям переопределять сообщение об ошибке

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

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

  Что произойдет, если валидатор не знает адрес? В некоторых случаях мы можем разрешить пользователям переопределять валидатор. (большой превью)

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

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

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

  Установите стоп-слова для ваших сообщений об ошибках

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

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

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

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

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

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

  Приведите примеры правильного ввода

  Говоря о выборе слов, как сделать его более полезным? И вообще, чем полезно сообщение об ошибке? Например, четкий набор рекомендаций о том, что такое правильный ввод. Это означает добавление подсказки под меткой, а — пример правильного ввода , чтобы пользователи понимали, как перенаправить и что от них ожидается.

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

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

  Отображение сводки ошибок наверху

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

  Рядом с кнопкой Отправить появляется сообщение об ошибке. Набросал Джордан Мур. (Большой предварительный просмотр)

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

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

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

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

  Подведение итогов

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

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

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

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

Если вас интересуют аналогичные идеи по UX, взгляните на Шаблоны проектирования интеллектуальных интерфейсов 9.0210 , наш блестящий новый 9-часовой видеокурс с 100 практическими примерами из реальных проектов.

This entry was posted in Популярное