Сообщение об ошибке


Содержание

Как правильно составлять сообщения об ошибках

Что не так с этими сообщениями об ошибках (и тысячами других, на них похожих)?

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

Почему эта ошибка в CoffeeScript так часто появлялась в вопросах на StackOverflow?

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

Контекст — наше все

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

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

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

Для Clojure-истов: используйте ex-info

Следующая информация предназначена только для тех, кто пишет на Clojure. Используйте функцию ex-info при дизайне исключений и указании контекста:

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

Как это касается меня?

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

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

Как написать идеальное сообщение об ошибке

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

Вот три ключевых момента для хорошего сообщения об ошибке:

  1. Понятный текст
  2. Правильное расположение
  3. Хороший дизайн

Понятный текст

1. Сообщение об ошибке должно быть понятным

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

2. Сообщение должно быть полезным

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

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

3. Сообщение об ошибке должно относиться к конкретной ситуации

Очень часто на сайтах используется одно сообщение об ошибке на все случаи жизни. Вы не заполнили поле — «введите валидный адрес электронной почты”, пропустили значок @ — “введите валидный адрес электронной почты”. MailChimp поступает по-другому: у них три разных сообщения об ошибке для каждой проверки валидности адреса. В первую очередь проверяется, что поле не было оставлено пустым, затем идёт проверка наличия символов “@” и “.”.(В любом случае “Введите корректное значение” — не лучшее сообщение об ошибке, ведь пользователю не понятно, какое значение будет корректным). Предлагайте пользователям актуальные сообщения, а не абстрактные.

4. Сообщение об ошибке должно быть вежливым

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

5. Пошутите, если это уместно

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

Правильное место сообщения

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

Правильный дизайн сообщения

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

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

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

СПРАВОЧНИК ПО VIM — Брам Мооленаар

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

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

1. Просмотр старых сообщений

Для просмотра старых сообщений используйте команду «:messages». Эта команда особенно полезна в тех случаях, когда старые сообщения были переписаны более новыми или были обрезаны при выводе (это зависит от значения опции ‘shortmess’).

Количество сообщений, хранящихся в истории равняется 20.

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

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

или (в переводе на другой язык):

Если вам лень нажимать кнопку shift, то сойдёт и так:

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

Если сообщение об ошибке исчезло раньше, чем вы смогли его прочитать, то можно прочитать его снова с помощью команды:

или, чтобы посмотреть весь список последних сообщений:

СПИСОК СООБЩЕНИЙ
E222, E228, E232, E256, E293, E298, E304, E317, E318, E356, E438, E439, E440, E316, E320, E322, E323, E341, E473, E570
Добавление в буфер чтения Add to read buffer
makemap: недопустимый режим makemap: Illegal mode
Невозможно создать BalloonEval с сообщением и обратной связью Cannot create BalloonEval with both message and callback
ОШИБКА автоматики Хангыл Hangul automata ERROR
блок не заблокирован block was not locked
Не получен блок номер ? Didn’t get block nr ?
ml_timestamp: Не получен блок 0?? ml_timestamp: Didn’t get block 0??
неправильное имя указателя блока pointer block id wrong
Обновлено слишком много блоков? Updated too many blocks?
ОШИБКА get_varp get_varp ERROR
u_undo: неправильные номера строк u_undo: line numbers wrong
список отмены поврежден undo list corrupt
нет строки отмены undo line missing
ml_get: не могу найти строку ml_get: cannot find line
Не могу найти строку cannot find line
номер строки за пределами нижней границы диапазона: line number out of range: past the end
неправильное количество строк в блоке line count wrong in block
Внутренняя ошибка Internal error
Критическая ошибка в cs_manage_matches fatal error in cs_manage_matches

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

ВНИМАНИЕ
Обнаружен своп-файл с именем …
ATTENTION
Found a swap file by the name …
Буфер не найден Buffer not found

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

Буфер с этим именем уже существует Buffer with this name already exists

Нельзя иметь два буфера с одинаковым именем.

Ошибка закрытия своп-файла Close error on swap file

Используемый для хранения копии редактируемого текста |своп-файл| не был закрыт как полагается. Это, как правило, довольно безобидное состояние.

Слишком рекурсивная команда Command too recursive

Это сообщение возникает, когда команда Ex выполняет другую команду Ex, которая в свою очередь выполняет другую команду Ex и т.д. Рекурсия в командах Ex ограничена 200 вложениями. Если таких вложений больше, то наиболее вероятно, что речь идёт о бесконечном цикле. Скорее всего, причиной такой ошибки может быть неправильная команда |:execute| или |:source|.

Невозможно назначить цвет Cannot allocate color

Цвет с именем <имя>не известен редактору. Список доступных в большинстве систем цветов см. |gui-цвета|.

Невозможно выделить память для цвета «xxxx»
Невозможно выделить память для цвета, цвет может отображаться некорректно
Cannot allocate colormap entry for «xxxx»
Cannot allocate colormap entry, some colors may be incorrect

Это означает, что для Vim осталось недостаточно цветов в системе. Vim будет работать, но цвета могут отображаться некорректно. Попробуйте закрыть приложение, которое использует слишком много цветов из таблицы, или запускайте это приложение после запуска gvim.
Занимать множество цветов из таблицы очень любит Netscape. Однако, ему можно подсказать пользоваться встроенной таблицей цветов:

или его можно ограничить в использовании системной таблицы цветов:

Это также можно сделать при помощи строки в файле Xdefaults:

Невозможно преобразовать маску Cannot expand wildcards

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

Невозможно вернуться в предыдущий каталог Cannot go back to previous directory

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

E190, E212
Невозможно открыть для записи файл «<имя_файла>»
Невозможно открыть файл для записи
Cannot open «» for writing
Can’t open file for writing

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

Невозможно открыть файл ссылки для записи Can’t open linked file for writing

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

Нельзя изменить значение переменной «<имя>» (доступна только для чтения) Cannot set read-only variable «»

Вы пытаетесь присвоить значение аргументу функции |a:var| или внутренней переменной Vim |v:var|, которая доступна только для чтения.

Невозможно выгрузить последний буфер из памяти Cannot unload last buffer

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

Невозможно открыть файл ошибок Can’t open errorfile

При использовании команды «:make» или «:grep»: файл, который использовался для сохранения сообщений об ошибках компилятора или вывода команды «grep» не может быть открыт. Для этого может быть несколько причин:

  • неправильное значение опции ‘shellredir’
  • изменение каталога в оболочке, из-за чего изменилось положение файла ошибок. Это можно исправить с помощью настройки опции ‘makeef’, однако команда make по прежнему будет выполняться в другом каталоге.
  • неправильное значение опции ‘makeef’.
  • программа, указанная в опции ‘grepprg’ или ‘makeprg’ не может быть выполнена. Это не всегда может быть распознано (особенно на MS-Windows). проверьте значение переменной окружения $PATH.
Невозможно открыть файл C:\TEMP\VIoD243.TMP Can’t open file C:\TEMP\VIoD243.TMP

Это сообщение появляется на MS-Windows, когда должен был быть прочитан вывод внешней программы, которая не была выполнена успешно. Это может быть вызвано несколькими причинами. Проверьте значение ‘shell’, ‘shellquote’, ‘shellxquote’, ‘shellslash’ и других соответствующих опций. Также это может быть вызвано тем, что внешняя программа не была найдена — для этой ситуации нет отдельного сообщения об ошибке.

Команда не допустима из exrc/vimrc в текущем каталоге или файле меток Command not allowed from exrc/vimrc in current dir or tag search

Некоторые команды не могут быть выполнены по требованиям безопасности. Чаще всего такое сообщение выдаётся при выполнении файла .exrc или .vimrc в текущем каталоге или в каталоге файла меток. См. также ‘secure’.


Слишком сложная команда Command too complex

Расшифровка привязки приводит к слишком длинной командной строке. Также может быть вызвано неявным вызовом привязки из самой привязки.

ОШИБКА ПРЕОБРАЗОВАНИЯ CONVERSION ERROR

Если при записи файла появляется текст «ОШИБКА ПРЕОБРАЗОВАНИЯ», то это означает, что преобразование файла из используемой внутри Vim кодировки UTF-8 в кодировку файла было выполнено с потерей данных. Файл будет помечен как содержащий изменения. Если вас беспокоит потеря информации, то установите такое значение опции ‘fileencoding’, которое позволит сохранить файл без потерь, и запишите файл снова. Если вас это не сильно заботит, то вы можете отключить опцию ‘modified’ или выйти из буфера.

Невозможно переименовать своп-файл Could not rename swap file

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

E43, E44
Поврежденная строка соответствий
Поврежденная программа регулярных выражений
Damaged match string
Corrupted regexp program

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

E208, E209, E210
Ошибка записи в «<файл>»
Ошибка закрытия «<файл>»
Ошибка чтения «<файл>»
Error writing to «»
Error closing «»
Error reading «»

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

Vim: Ошибка чтения ввода, выход… Vim: Error reading input, exiting…

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

Ошибка чтения файла ошибок Error while reading errorfile

Чтение файла ошибок невозможно. Это сообщение НЕ связано с неспособностью Vim распознать то или иное сообщение в файле ошибок.

Ошибка при записи Error while writing

Запись файла не была завершена корректно. Файл может быть записан не полностью.

E13, E189
Файл уже существует (добавьте !, чтобы обойти проверку)
«<файл>» существует (!, чтобы обойти проверку)
File exists (use ! to override)
«» exists (use ! to override)

Vim предохраняет вас от случайной перезаписи файла. Если вы хотите всё-таки записать файл, то используйте ту же самую команду, но с добавлением «!» сразу после команды. Например:

Файл загружен в другой буфер File is loaded in another buffer

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

Файл не сохранён: запись отменена опцией ‘write’ File not written: Writing is disabled by ‘write’ option

Отключена опция ‘write’, в результате чего выполнение любой команды, которая пытается записать файл, приводит к появлению этого сообщения. Это также может быть вызвано запуском Vim с аргументом |-m| в командной строке. Вы можете включить опцию ‘write’ с помощью команды «:set write».

Возможность использования GUI не включена во время компиляции GUI cannot be used: Not enabled at compile time

Вы работаете в версии Vim, в которую не включён графический интерфейс, из-за чего команды «gvim» и «:gui» работать не будут.

Неправильная величина прокрутки Invalid scroll size

Сообщение вызвано неправильным значением для опций ‘scroll’, ‘scrolljump’ или ‘scrolloff’.

«<имя файла>» это каталог «» is a directory

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

Отметка указывает на неправильный номер строки Mark has invalid line number

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

E219, E220
Пропущена <.
Пропущена >.
Missing <.
Missing >.

В имени файла используется конструкция <>, но при этом не было указано пары для той или иной фигурной скобки. Эта конструкция должна быть использована так: , что означает соответствие «foo» и «bar».

ml_get: неправильный lnum: ml_get: invalid lnum:

Это внутренняя ошибка Vim. Постарайтесь воспроизвести эту ошибку и отправьте сообщение разработчикам. |bugreport.vim|.

Есть неотредактированные файлы (<число>) more files to edit

Вы пытались выйти из Vim в то время как в списке аргументов остались неотредактированные файлы. Это предохраняет вас от выхода из редактора, когда вы не выполнили всю работу, которую планировали. См. |список_аргументов|. Если вы действительно хотите выйти, то просто повторите команду выхода — на второй раз она сработает.

E23, E194
Нет соседнего файла
Нет соседнего файла для подстановки вместо ‘#’
No alternate file
No alternate file name to substitute for ‘#’

Соседний файл ещё не определён. См. |соседний_файл|.

Нет имени файла No file name

Текущий буфер не имеет имени. Для записи используйте команду «:w имя_файла». Или вы можете дать буферу имя с помощью команды «:file имя_файла».

У буфера <номер>отсутствует имя No file name for buffer

Один из изменённых буферов не имеет имени и поэтому не может быть записан. Вам следует дать буферу имя:

Нет предыдущего шаблона для подстановки No previous substitute regular expression

При использовании в шаблоне символа ‘

’, он заменяется на раннее использованный в команде «:substitute» шаблон. Если команда ещё не использовалась, то это не будет работать. См. |/

Предыдущее регулярное выражение отсутствует No previous regular expression

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

Нет такого сокращения No such abbreviation

Вы использовали в команде «:unabbreviate» аргумент, который не является существующим сокращением. Такое сообщение выдают все варианты этой команды: «:cunabbrev», «:iunabbrev» и т.д. Проверьте наличие пробелов в конце сокращения.

Сообщение выдаётся только для GTK GUI с поддержкой Gnome. Gnome пытается использовать несуществующее звуковое устройство. Эту ошибку можно игнорировать.

Указанная привязка не существует No such mapping

Вы использовали в команде «:unmap» аргумент, который не является существующей привязкой. Такое сообщение выдают все варианты этой команды: «:cunmap», «:unmap!» и т.д. Проверьте наличие пробелов в конце привязки.

E37, E89
Изменения не сохранены (добавьте !, чтобы обойти проверку)
Изменения в буфере не сохранены (!, чтобы обойти проверку)
No write since last change (use ! to override)
No write since last change for buffer (use ! to override)

Вы пытаетесь |бросить| редактирование изменённого файла. Vim предохраняет вас от потери результатов работы. Вы можете либо записать файл с помощью команды «w:», либо, если вы уверены, |бросить| файл и потерять все несохранённые изменения. Это можно сделать, добавляя символ ‘!’ сразу после команды.

Несохранённые изменения в буфере «<имя>» No write since last change for buffer «»

Это сообщение появляется при попытке выхода из Vim с несохранёнными изменениями в некоторых буферах. Вы можете либо записать изменения в буфере (по команде |:w|), либо использовать соответствующую команду для насильного выхода, например «:qa!». Будьте внимательны, чтобы не потерять изменения, которые вы желаете сохранить. Возможно, вы забыли о каком-либо буфере, особенно если у буфера включена опция ‘hidden’.

Аргумент равен NULL Null argument

Ошибка внутри Vim привела к появлению указателя со значением NULL. Если вы знаете, как воспроизвести проблему, то сообщите пожалуйста разработчикам. |глюки|.

Разрешено использовать только одно имя файла Only one file name allowed

Команда «:edit» допускает только одно имя файла. Если вы хотите указать несколько файлов, то используйте команду «:next» |:next|.

E41, E82, E83, E342
Не хватает памяти!
Не хватает памяти! (требуется <число>байт)
Нельзя выделить память ни для одного буфера, выход…
Нельзя выделить память для буфера, используется другой буфер…
Out of memory!
Out of memory! (allocating bytes)
Cannot allocate any buffer, exiting…
Cannot allocate buffer, using other one…

Мда. Похоже, вы делаете что-то очень сложное, или какая-нибудь другая программа съела всю свободную память. Будьте внимательны! Vim не очень хорошо справляется с подобными ситуациями. Убедитесь, что все изменения сохранены. Постарайтесь решить проблему с нехваткой памяти. Лучше всего, выйдите из Vim и запустите его снова. См. также |msdos-ограничения|.

Слишком длинный шаблон Pattern too long

Это происходит только на системах с 16-битными целыми: скомпилированный шаблон регулярного выражения занимает более 65000 символов. Постарайтесь использовать более короткий шаблон.

Включена опция ‘readonly’ (добавьте !, чтобы обойти проверку) ‘readonly’ option is set (use ! to override)

Вы пытаетесь записать файл, для которого установлен режим «только для чтения». Для записи этого файла необходимо либо выключить опцию ‘readonly’, либо добавить к команде символ ‘!’. Пример:

следует изменить на:

E294, E295, E301
Ошибка чтения своп-файла
Ошибка поиска при чтении своп-файла
Ну и дела, потерялся своп-файл.
Read error in swap file
Seek error in swap file read
Oops, lost the swap file.

Vim столкнулся с проблемой при чтении текста из |своп-файла|. Текст в соответствующем буфере может быть повреждён! Перед записью буфера всё внимательно проверьте. Вы можете записать буфер в другой файл и сравнить различия.

Слишком большая рекурсия при использовании :normal Recursive use of :normal too deep

Вы используете команду «:normal», аргумент которой рекурсивно использует команду «:normal». Максимально допустимая величина рекурсии определяется настройкой опции ‘maxmapdepth’. Пример команды, которая приводит к выдаче этого сообщения:

При вводе команды «gq» будет вызвано выполнение привязки, которая, в свою очередь, выполняет команду «gq».

Сценарии слишком глубоко вложены друг в друга Scripts nested too deep

Сценарии могут считываться при помощи аргумента командной строки «-s» или с помощью команды «:source». Сценарий может считывать другой сценарий. Так может продолжаться до 14 уровней. При более глубоких вложениях сценариев Vim считает, что возник бесконечный цикл и останавливается с выдачей этого сообщения об ошибке.

Извините, эта команда недоступна в данной версии Sorry, the command is not available in this version

Вы пытались использовать команду, которая недоступна в вашей версии Vim. При компиляции Vim можно включать или отключать те или иные особенности. Это зависит от того, насколько большим Vim вам хочется пользоваться. Список особенностей см. в |+особенности-список|. Команда |:version| позволяет показать включённые при компиляции особенности для вашего Vim.

Своп-файл уже существует (атака с использованием символьной ссылки?) Swap file already exists (symlink attack?)

Это сообщение возникает в тех случаях, когда Vim пытается открыть своп-файл, и обнаруживает, что он уже существует, или обнаруживает на его месте символическую ссылку. Этого не должно происходить, поскольку Vim перед этим уже проверял, что файл не существует. Либо кто-то открыл этот же файл одновременно с вами (маловероятно), или кто-то пытается предпринять атаку с помощью символьной ссылки (что возможно при редактировании файла в /tmp или в тех случаях, когда значение опции ‘directory’ начинается с «/tmp», что совсем нельзя считать хорошим выбором).

Файл меток не отсортирован: Tags file not sorted:

Vim (и Vi) предполагают, что файл меток отсортирован в соответствии с таблицей ASCII. В этом случае можно пользоваться бинарным поиском, который намного быстрее, чем линейный поиск. Если ваш файл меток не отсортирован должным образом, то отключите опцию |’tagbsearch’|.

Это сообщение выдаётся только в том случае, когда Vim обнаруживает проблему при поиске меток, и то не всегда.

Ресурсная вилка будет утрачена (добавьте !, чтобы обойти проверку) The resource fork would be lost (add ! to override)

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

Используется слишком много разных атрибутов подсветки синтаксиса Too many different highlighting attributes in use

Vim может работать только с 223 различными атрибутами для подсветки синтаксиса. Это ограничение можно превысить, если использовать слишком много команд |:highlight| с различными аргументами. Команда «:highlight link» при этом не учитывается.


Слишком много имён файлов Too many file names

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

Невозможно открыть своп-файл для «<имя файла>», восстановление невозможно Unable to open swap file for «», recovery impossible

Vim не смог открыть своп-файл. Вы можете продолжить редактирование файла, но при внезапном завершении работы все изменения будут потеряны. Кроме того, при редактировании большого файла Vim будет использовать много оперативной памяти. Возможно, вам следует проверить значение опции ‘directory’, чтобы избежать появления этой ошибки. См. |своп-файл|.

Для записи части буфера используйте ! Use ! to write partial buffer

При использовании диапазона для записи части буфера очень редко действительно необходимо перезаписать существующий файл. Поскольку это скорее всего ошибка (например, команда «:w» используется в Визуальном режиме), то Vim требует добавления ! к команде записи. Например: «:3,10w!».

Предупреждение: Невозможно преобразовать строку « Escape,_Key_Cancel» в виртуальную привязку Warning: Cannot convert string « Escape,_Key_Cancel» to type VirtualBinding

Подобные сообщения могут появляться при запуске. Это не проблема Vim, но, по видимому, у вас неправильно настроен сервер X11. Совет по решению данной проблемы можно найти здесь: http://groups.yahoo.com/group/solarisonintel/message/12179.

Предупреждение: изменение файла, открытого только для чтения Warning: Changing a readonly file

Вы пытаетесь внести изменения в файл, несмотря на то, что он доступен только для чтения. Чтобы избежать появления этого сообщения, вы можете настроить автокоманду |FileChangedRO| (автокоманда должна выключать опцию ‘readonly’). Чтобы полностью запретить внесение изменений в файл, смотрите справку по опции ‘modifiable’.

Предупреждение: файл «<имя файла>» создан после начала редактирования Warning: File «» has been created after editing started

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

Предупреждение: файл «<имя файла>» был изменен после начала редактирования Warning: File «» has changed since editing started

Файл, который вы начали редактировать, имеет изменённую дату и содержание (говоря точнее: если вы прочитаете с существующими опциями и автокомандами этот файл заново, то у вас в буфере будет другой текст). Наиболее вероятно, что текст был изменён в другой программе. Вам следует выяснить, что произошло, и решить, какую версию файла следует сохранить. Если вы желаете делать это автоматически, то включите опцию ‘autoread’. Это сообщение не выдаётся, если значением опции ‘buftype’ не является пустая строка.

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

добавьте в файл autoexec.bat строку:

Вместо «-1» укажите ваш часовой пояс.

  • отключите «автоматическую подстройку часов при переходе на летнее время».
  • запишите файл ещё раз на следующий день или установите часы на следующий день, запишите файл дважды и верните часы назад.
  • Предупреждение: файл «<имя файла>» и буфер Vim были изменены независимо друг от друга Warning: File «» has changed and the buffer was changed in Vim as well

    Та же ситуация, что и в предыдущем предупреждении, но также был изменён и буфер Vim, открытый для этого файла. Вам необходимо решить: сохранить версию файла, записанную на диске, или ту, которая открыта в Vim. Это сообщение выводится только в том случае, когда значение опции ‘buftype’ равно пустой строке.

    Предупреждение: права на файл «<имя файла>» были изменены после начала редактирования Warning: Mode of file «» has changed since editing started

    Это сообщение выдаётся в тех случаях, когда изменились права доступа к файлу, без изменения содержимого буфера. Чаще всего это происходит, когда файл забирается из хранилища системы управления версиями, что приводит к изменению прав на запись. Перезагрузка файла не должна вызвать осложнений. Для автоматической перезагрузки файла включите опцию ‘autoread’.

    Предупреждение: файл «<имя файла>» больше не доступен Warning: File «» no longer available

    Файл, который вы начали редактировать был удалён или недоступен. Убедитесь, что все ваши изменения будут сохранены. Это сообщение выводится только в том случае, когда значение опции ‘buftype’ равно пустой строке.

    Предупреждение: список имен файлов переполнен Warning: List of file names overflow

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

    E296, E297
    Ошибка поиска при записи своп-файла
    Ошибка записи своп-файла
    Seek error in swap file write
    Write error in swap file

    Наиболее вероятно, что у вас кончилось место на диске. Vim не смог записать текст в |своп-файл|. Эта ошибка не является фатальной, но если произойдёт какая-либо авария, то вы не сможете восстановить изменения в тексте файла. Vim также может начать испытывать недостаток памяти.

    Xlib: connection to « или , чтобы обновить экран и продолжить работу. Нажатая кнопка больше ни на что не влияет.
  • Нажмите «:» или введите любую команду Обычного режима, чтобы сразу перейти к выполнению этой команды.
  • Нажмите для копирования безрежимного выделения в регистр буфера обмена.
  • Воспользуйтесь меню. Используются символы, определённые для режима командной строки.
  • Если в значении опции ‘mouse’ указан флаг ‘r’, то нажатие на левую кнопку мыши идентично нажатию на кнопку . Однако, в этом случае невозможно выделение текста.
  • В графическом интерфейсе нажатие на левую кнопку мыши в последней строке идентично нажатию на кнопку .
  • Vi: распознаются только «:»-команды.

    Чтобы уменьшить количество сообщений «нажмите enter»:

    • Установите значение опции ‘cmdheight’ равным 2 и более строки.
    • Добавьте соответствующие флаги к значению опции ‘cmdheight’.
    • Выключите опцию ‘showcmd’ и/или ‘ruler’.

    См. также справку по опции ‘mouse’. Это сообщение выделяется с помощью группы подсветки |hl-Question|.

    — Продолжение следует —
    — Продолжение следует — (RET: строка, SPACE: страница, d: полстраницы, q: выход)
    — Продолжение следует — (RET/BS: строка, SPACE/b: страница, d/u: полстраницы, q: выход)
    — More —
    — More — (RET: line, SPACE: page, d: half page, q: quit)
    — More — (RET/BS: line, SPACE/b: page, d/u: half page, q: quit)

    Это сообщение выводится в тех случаях, когда вывод не умещается на экране. Оно выдаётся только при включённой опции ‘more’. Сообщение выделяется с помощью группы подсветки |hl-MoreMsg|.

    Ввод эффект
    или или j или показать ещё одну строку
    или k или на одну строку назад (*)
    или

    следующая страница
    b или

    предыдущая страница (*)
    d на полстраницы вниз
    u на полстраницы вверх (*)
    q, или CTRL-C остановить просмотр
    : остановить просмотр и перейти в командную строку
    скопировать безрежимное выделение в буфер обмена (регистры «* и «+)
    меню, определённое в режиме командной строки
    (**) следующая страница

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

    (*) прокрутка назад поддерживается только для следующих команд:

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

    • в графическом интерфейсе: в последней строке экрана.
    • если в значении опции ‘mouse’ указан флаг ‘r’ (при этом, однако, не работает выделение текста).

    Замечание: введённый символ напрямую принимается с терминала. Привязки не учитываются. Упреждающий ввод игнорируется.

    Искусство вывода сообщений об ошибках

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

    Почему сообщения об ошибках имеют значение

    Вероятно, мы все время от времени видим ошибку «неправильного пароля. Хотя, может расстраивать, когда все работает не так, как ожидалось, мы просто не обращаем на это внимание. Но каков суммарный эффект от этих небольших моментов?

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

    Подумайте о различиях между тем, что вы видите:

    И, например, более действенным вариантом:

    Так что же могут сделать команды разработчиков?

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

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

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

    Правила вывода сообщений об ошибках

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

    1. Скажите, что произошло и почему

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

    Представьте, что вы используйте пробную версию Spotify Premium. Затем вы попадаете на страницу и видите что-то вроде этого сообщения:

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

    В этом случае важно сообщить пользователю, что произошло и почему.

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

    2. Предложите следующий шаг

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

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

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

    3. Найдите нужный тон

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

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

    ОК. Итак, как правильный тон? Вы можете начать с вопроса:

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

    Искусство вывода сообщений об ошибках — резюме

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

    В следующий раз, когда вы пишете сообщение об ошибке, помните об этих советах:

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

    Сообщения об ошибках — как повысить эффективность лид-форм

    Baymard Institute провел исследование, как сайты сообщают пользователям об ошибках в заполнении полей форм. Только 9% компаний используют адаптивные сообщения об ошибках. Остальные 91% сайтов выдает стандартные сообщения.


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

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

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

    Универсальные сообщения об ошибках

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

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

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

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

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

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

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

    Если пользователь не понимает, где допущена ошибка, он может пойти двумя путями:

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

    Адаптивные сообщения об ошибках

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

    Рассмотрим пример. Пользователь вводит адрес электронной почты «snezhcka@gmail», тогда адаптивное сообщение прозвучит следующим образом:

    Вы не указали домен высшего уровня, такой как .com, .ru, .net

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

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

    Пожалуйста, укажите номер телефона без кода страны. Не используйте пробелы, скобки, дефисы и другие разделители.

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

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

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

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

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

    Адаптивные сообщения об ошибках: есть ли альтернативы?

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

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

    Какие есть альтернативы:

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

    Ни один из этих методов не исключает ошибок, допускаемых пользователями каждый раз при заполнении форм. Люк Вроблевкски (Luke Wroblewski), юзабилити-эксперт, автор книг Mobile First и Web Form Design, провел исследование встроенной валидации в сравнении с обычным методом проверки. Результаты исследований показали:

    • количество успешно заполненных форм возросло на 22%
    • количество допущенных ошибок уменьшилось на 22%
    • оценочный коэффициент удовлетворенности увеличился на 31%
    • время заполнения формы сократилось на 42%
    • количество зрительных фиксаций сократилось на 47%

    Якоб Нильсен, юзабилити эксперт, разработал рекомендации, каким должно быть сообщение об ошибке:

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

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

    «Вы использовали один из недопустимых символов в пароле «!;№%:?*()@#$&. Попробуйте еще раз. Мы в Вас верим!»

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

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

    Советы по исправлению — вместо того, чтобы указывать только на ошибку, объясните пользователю, как ее исправить. Сравним:

    Неверный формат ввода телефона

    Вы ввели номер телефона в неверном формате. Не используйте пробелы. Укажите номер без дефисов/скобок/пробелов.

    Рекомендации GetGoodRank по повышению эффективности лид-форм:

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

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

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

    Как написать идеальное сообщение об ошибке

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

    Вот 3 жизненно важных части любого хорошего сообщения об ошибке:

    • Четкое текстовое сообщение
    • Правильное размещение
    • Хороший визуальный дизайн

    Четкое текстовое сообщение

    1. Сообщение об ошибке должно быть понятным

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

    2. Сообщение об ошибке должно быть полезным

    Не достаточно просто написать, что что-то пошло не так. Покажите пользователю, как он может исправить проблему.

    Например, Microsoft описывает проблему, и прямо в сообщении об ошибке предоставляет вариант ее решения.

    3. Сообщение об ошибке должно подходить под определенную ситуацию

    Очень часто, веб-сайты используют одно сообщение об ошибке для всех схожих состояний. Оставили пустым поле ввода электронного адреса — «Введите правильный электронный адрес», пропустили символ «@» — «Введите правильный электронный адрес». MailChimp решает эту проблему иначе – они используют 3 разных сообщения об ошибке для каждого состояния процесса подтверждения электронной почты. Сначала проверяется, заполнено ли поле ввода. Затем проверяется введены ли символы «@», и «.».

    4. Сообщение об ошибке должно быть вежливым

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

    5. Используйте юмор, если он уместен

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

    Правильное размещение

    Хорошее сообщение об ошибке – это такое сообщение, которое вы увидите. Размещайте его рядом с элементами интерфейса, с которыми ошибка непосредственно связана.

    Правильный визуальный дизайн

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

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

    Заключение

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

    Сообщение об ошибке — Error message

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

    содержание

    Общие сообщения об ошибках

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

    Доступ закрыт Эта ошибка возникает , если пользователь не имеет достаточные привилегии для файла, или если он был заблокирован какой — либо программой или пользователем. Устройство не готово Эта ошибка чаще всего возникает , когда нет дискеты (или плохой диск) в дисковод и система пытается выполнить задачи , связанные с этим диском. Файл не найден Файл обеспокоен , возможно, были повреждены, перемещены, удалены, или ошибка может быть причиной ошибки. Кроме того , файл просто не может существовать, или пользователь неправильно набранный свое имя. Более частое включение интерфейсов командной строки , чем на графических пользовательских интерфейсов , где файлы представлены иконически и пользователи имена файлов не печатаете. Недостаточно места на диске Эта ошибка возникает , когда жесткий диск (почти) полностью. Чтобы исправить это, пользователь должен закрыть некоторые программы (для свободного файла подкачки использования) и удалить некоторые файлы ( как правило , временные файлы или другие файлы после того, как они были скопированы), или получить больший жесткий диск. Недостаточно памяти Эта ошибка возникает , когда система запуска из памяти или пытается загрузить файл слишком большой , чтобы хранить в памяти . Исправление закрыть некоторые программы, или установить дополнительную память. [Название программы] столкнулась с проблемой и необходимо закрыть. Приносим свои извинения за неудобства. Это сообщение отображаются на Microsoft Windows XP , когда программа вызывает общую ошибку защиты или недопустимую ошибку страницы . В Windows 7 он превращается в более простой «[название программы] перестал работать».

    Заметные сообщения об ошибках

    • Прервать, Retry, нормально? — сообщение заведомо запутанная ошибка видела в MS-DOS

    Сбой домашних животных

    С появлением Web 2.0 сервисов , такими как Twitter , конечный пользователь сталкивается с сообщениями об ошибках , таких как HTTP 404 и HTTP 500 начал отображаться с причудливыми символами, называемых Fail домашних животных или талисманы ошибок. Термин «Сбой Pet» был придуман, или , по крайней мере , первым использовал в печати, по Mozilla инженер Фред Венцель в пост на своем блоге под названием «Почему Википедия может понадобиться домашнее животное потерпеть неудачу, — и почему Mozilla не делает.» Доктор Шон Rintel утверждает , что сообщения об ошибках являются важным стратегическим моментом в узнаваемости бренда и лояльности. Нормально Домашние животные представляют интерес для маркетологов , так как они могут привести к узнаваемости бренда (особенно через заработанные средства массовой информации ). «Тем не менее, что же признание несет опасность выделения сбоя в работе.» Самый известный провал животное щебетать Fail Whale (см Twitter перебоев в обслуживании). Другие домашние животные не в состоянии включать в себя:

    • Ars Technica : Moon Shark
    • FarmVille на Facebook: унылая корова.
    • GitHub : Octocat
    • Google : Broken робот
    • ICloud : Облако с Apple System лицом 7 смайлика стиля
    • Macintosh : Sad Mac
    • Tumblr : Tumbeasts
    • Twitter : Fail Whale / Twitter Робот
    • YouTube : Телевизоры (на главной странице), свет статического внутри окна видео (встроенное видео)
    • Cartoon Network : BMO [Азия]: Domo
    • Google Chrome : T-Rex

    формат сообщения

    Форма, сообщения об ошибках принимают варьируется между операционными системами и программами.

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

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


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

    • Диалоговое окно или всплывающее сообщение появляется в окне на экране, блокируя дальнейшее взаимодействие с компьютером , пока не будет подтверждено. В Mac OS X, листы представляют собой форму диалогового окна, которые прикреплены к определенному окну.
    • Значки уведомлений появляются уведомления пользователя о состоянии , не прерывая их работу. В операционной системе Windows, значки уведомлений появляется в системном трее. В Mac OS X, значки уведомлений могут появиться в строке меню, или могут иметь форму отображается иконка приложения «прыгающей» в доке. GNOME интерфейс пользователя для систем Unix может отображать значки уведомлений в панели.
    • Незначительные ошибки могут отображаться в строке состояния , небольшой часть окна приложения , которое может отображать краткие сообщения пользователя.

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

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

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

    Безопасность

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

    Правила написания сообщений об ошибках. Юзабилити: чего стоит избегать в сообщениях об ошибках

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

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

    Пожалуйста, запомните! В более поздних версиях MSIE и Navigator это окошко может не появляться.

    При использовании MSIE сообщение об ошибке появится сначала как треугольный значок в нижнем левом углу. В этом треугольнике будет находиться восклицательный знак. Будет также присутствовать текст, сообщающий, что на странице встретились ошибки. Щелкните на этом треугольнике, чтобы получить сообщение об ошибке , которое рассматривается в данном учебнике. Или, если вы хотите, чтобы окно ошибки выводилось сразу, без щелчка на значке, перейдите в меню Tools (Сервис) и выберите Internet Options (Свойства обозревателя). В Internet Options щелкните на вкладке Advanced (Дополнительно) и поставьте флажок у строки «Display a notification about every script error » (Показывать уведомление о каждой ошибке сценария).

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

    При использовании более поздней версии Netscape Navigator в строке состояния выводятся указания пользователю. При возникновении ошибки будет предложено ввести javascript : в строке адреса. Затем будет выведена ошибка и соответствующее текстовое описание.

    Сообщение об ошибке

    В основном ошибки бывают двух типов: синтаксиса и времени выполнения. Ошибка синтаксиса означает опечатку или неправильную конфигурацию JavaScript . Ошибка времени выполнения означает, что была использована неправильная команда . В любом случае получается ошибка. Где-то что-то было перепутано.

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

    Исправление ошибок

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

    В этих всплывающих окошках сообщений об ошибке есть одна замечательная вещь: они сами говорят, где и в чем состоит проблема. Взгляните на сообщение. У нас синтаксическая ошибка, означающая неправильную конфигурацию сценария, и находится она на строке 29. Более того, сообщение об ошибке прямо указывает на проблемную область. Было бы неплохо иметь такое и в HTML ?

    Строка ошибки

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

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

    Счастливый путь

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

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

    • 31% процент сразу делали ошибки;
    • 7% из них смогли успешно продолжить;
    • 24% из них ушли с сайта после нескольких попыток.

    Как лучше всего поступать с ошибками людей?

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

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

    Красный текст под нужным полем тоже хороший пример.

    Этот сайт про обувь ясно дает понять в чем проблема. Сообщение расположено около проблемного поля.

    Встроенная проверка и сообщения
    об ошибке

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

    Хорошо о встроенной проверке написал Luke Wroblewski в журнале A List Apart .

    У этого метода есть свои недостатки:

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

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

    Как формулировать
    сообщения об ошибке

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

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

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

    В работе над новым сайтом можно полагаться на прошлый опыт: вам будет понятно какие ошибки делают люди. Запустив сайт необходимо проследить не появились ли новые трудности у посетителей.

    Ваше сообщение об ошибке должно:

    • быть тактичным и избегать обвинений пользователя («упс» хорошее слово);
    • четко объяснять что не так;
    • помогать исправить ситуацию.

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

    Вот пример того как не надо делать с полем для ввода электронной почты.
    Нам всем понятно что не так, но сайт предлагает нам читать целый параграф возможных проблем. Как на счет «В вашем адресе не хватает знака “@”»?

    Для других проблем понадобятся иные сообщения:

    [email protected] => «Адрес введен не до конца, проверьте окончание»
    bob./[email protected] => «В адресе встречается не обычный символ (/)»

    Вот как надо делать для часто повторяющихся проблем и только потом использовать некий «шаблон» для неизвестных ошибок человека.

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

    Пустые поля

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

    Мой совет на такой случай — объясните посетителю зачем вам его данные:

    • «Нам нужен вам телефон, потому что наш водитель может опоздать»
    • «Введите вашу почту, чтобы мы могли напоминать вам пароль»
    • «Введите почтовый индекс, чтобы посылка дошла быстрее»

    Улучшение на 17%

    Одна финансовая компания воспользовалась этими рекомендациями. Вот какие данные были изначально:

    • 100 попыток регистрации;
    • 31 ошибка у регистрирующихся впервые;
    • 7 все-таки зарегистрировались;
    • 24 не закончили регистрацию.

    Было: 76% успешных регистраций из всех (100% — 24%)
    Стало: 89% успешных регистраций.

    Фишка заключалась в возвращении посетителя на «счастливый путь» и это удавалось сделать хорошими сообщениями об ошибке.

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

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

    Что такое сообщение об ошибке?

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

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

    Легче предупредить, чем исправить

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

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

    Мудрое решение в этом случае представляет Booking.com: их селектор диапазона дат позволяет выбрать только текущую или последующие даты, и человек таким образом никак не сможет ошибиться.

    Сообщения об ошибках неправильного ввода данных

    Валидация форм необходима для сообщения пользователю об имеющихся неточностях в введенных им данных. Хорошая валидация формы содержит четыре важных элемента:

    1. Правильное время (встроенная валидация)

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

    Валидация должна незамедлительно информировать пользователей о правильности введенной ими информации. Главный принцип хорошей валидации формы таков: Разговаривайте с пользователями! Говорите им, что идет не так! Это поможет им сократить время на исправление ошибок.

    2. Правильное место

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

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

    3. Правильный цвет (интуитивный дизайн)

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

    4. Понятное сообщение

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

    Ошибки приложений

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

    Вы никогда не должны показывать сообщения следующего рода:

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


    Это сообщение об ошибке было написано разработчиком для разработчика: «Операция не может быть завершена (WDGeneralNetworkError 500)»

    2. Тупиковое сообщение. Такие сообщения не дают никакой полезной информации для пользователей.

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

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

    Ваше сообщение об ошибке должно четко и понятным для пользователя языком информировать о том:

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

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

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

    В Gmail при создании нового аккаунта можно натолкнуться на такое сообщение об ошибке.

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

    Правила создания эффективных сообщений об ошибках не меняются вот уже 20 лет. Хорошее сообщение об ошибке должно:

    • Явно указывать, что что-то не так. Самое плохое сообщение об ошибке это то, которое не было создано. Если пользователи делают ошибку и не получают никакого отклика от системы, это самое худшее для них. Например, приложение работы с электронной почтой имеет несколько ситуаций, где указание о произошедшей ошибке было бы явно полезным. Скажем, вы отправили почтовое сообщение, которое было благополучно проглочено системой, но так и не достигло адресата. Еще пример? Вы сообщаете в письме, что прилагаете к нему файл, но просто забыли сделать это. Вот тут-то и нашлась бы работа для этой глупой скрепки из MS Office: «Похоже, вы хотели прикрепить файл к вашему сообщению, но не сделали этого. Хотите сделать это? «
    • Быть написано на человеческом языке , а не с использованием таинственных кодов и сокращений типа «произошла ошибка типа 2 «.
    • Быть вежливым и не обвинять пользователей в том, что они такие глупые или сделали что-то не так, как например в сообщении «запрещенная команда «
    • Точно описывать источник проблемы, а не просто выдавать общие фразы типа «синтаксическая ошибка «.
    • Давать конструктивный совет о том, как исправить проблему. Например, вместо того, чтобы сообщать о том, что товара «нет в наличии «, ваше сообщение об ошибке должно либо сообщать, когда товар будет в наличии, или предлагать пользователям настроить отсылку им сообщения-уведомления , когда товар появится в наличии.

    Самая распространенная ошибка в Web — 404 — нарушает большинство из этих правил. Я рекомендую вам написать свое собственное сообщение об ошибке 404 вместо того, чтобы полагаться на скупую серверную фразу «page not found».

    Новые правила

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

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

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

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

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

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

    Обучение пользователей

    И наконец, вы наверное уже знаете Первый Закон Нильсена о компьютерной документации : люди ее не читают . Этот закон действует еще сильнее для веб-сайтов, где пользователи действительно избегают читать то, что не существенно для их задачи. Щелкнуть по ссылке «Помощь»? Да ни за что.

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

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

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

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

    «Помощь: Как правильно создать пароль?»

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

    Самое худшее — это неоднозначные сообщения, которые не дают ответа на вопрос: «Что здесь не так?». Вот как выглядит страница Amazon, по какой-то причине не принимающая промо-код:

    «Введенный промо-код не может быть использован для этой покупки». Почему?!

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

    График зависимости производительности от уровня стресса, слева направо: спокойное состояние, «полезный» стресс, дистресс (вреден для здоровья)

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

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

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

    Если вы специально все перепутаете (так, будто форму заполняет далекий от Интернета человек), то получите следующий результат:

    «Поле “обращение” должно быть заполнено»

    Так, вы забыли указать, кто вы — «мистер» или «миссис». После исправления появляется другая ошибка:

    Что-то не так с email? Забыли.com, но это несложно исправить:

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

    «Введенный адрес электронной почты уже используется пользователем FreeSpirit. Используйте другой адрес»

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

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

    Проблема №1: Двусмысленность

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

    «Ваш email не может быть отправлен»

    Почему? Как пользователь должен это понять?

    Сервис Bitly просто утомляет подобными сообщениями, которые не объясняют конкретно, что не так. Имя пользователя? Пароль? И то, и другое? Помогите человеку понять, в чем он ошибся:

    «Нет, попробуйте еще раз»

    Это довольно частая проблема.

    Приятно, когда ошибки в форме ярко выделены по отношению к другим, правильно заполненным полям. Например, на Meetup.com всегда точно показано, в каком именно месте возникла неточность или проблема и что с этим делать:

    «Извините, произошла ошибка. Детали ошибки выделены цветом ниже»

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

    Проблема №2: Снисходительный тон/обвинение пользователя

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

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

    «Мы уже трижды предупреждали вас, что этот файл не существует. Не делайте так снова»

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

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

    Проблема №3: Неправильное расположение сообщений об ошибках

    Вот что пишет UXMovement в своей статье:

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

    Что может быть более пугающим, чем увидеть что-то вроде этого в момент, когда вы готовы нажать «Отправить»?

    «Ошибки, которые были найдены при заполнении, пожалуйте, исправьте их и снова подтвердите форму»

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

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

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

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

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

    «Ваш пароль должен содержать от 4 до 60 символов»

    Проблема №4: Неясные ожидания

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

    Многие сообщения об ошибках не дают представления о следующем шаге. Как в примере со Spirit Airlines: они могли бы предоставить несколько возможностей восстановить доступ к аккаунту или спросить: «У вас уже был аккаунт? Войдите здесь». Вместо этого они просто сообщают, что ваш email уже используется.

    «Этот email уже используется, укажите другой»

    Отличное сообщение об ошибке, которое учит пользователя и помогает исправить ее, предлагает MailChimp::

    «Извините, мы не нашли аккаунт с таким именем. Помочь вам восстановить имя пользователя?»

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

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

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

    «Убедитесь, что вводите адрес, привязанный к кредитной карте»

    Вот еще один пример, где помог бы текст с инструкцией:

    «Пожалуйста, введите числовое значение»

    Пип Лайа (Peep Laja) пытался заполнить форму на веб-сайте для получения ссылки на событие. Однако в результате он был возвращен на первую страницу, содержащую большое красное сообщение «Возникла проблема с вашей подпиской», полное неопределенности.

    Суть была в том, что он ввел в поле «Число гостей» слово «Несколько» (разумно, учитывая, что достаточно сложно просчитать количество гостей для события), но форма подразумевала точное число. Конечно, об этом не было ни слова до того, как он нажал «Отправить»: микротекст в этой ситуации оказлся бы очень полезным.
    (Хотя именно в этом примере проблем гораздо больше, чем просто отсутствие пояснений).

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

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

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

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


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

    Лучшие примеры сообщений об ошибках, проверенные годами

    «Нильсен Норман Груп» предложили следующие лучшие практики сообщений об ошибках еще в 2001 году — и они до сих пор работают:

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

    У UXMas есть полезное правило, касающееся сообщения об ошибке, которое они называют «4Н». Согласно этому правилу, сообщение об ошибке должно быть:

    1. Человечным (Human)
    2. Полезным (Helpful)
    3. Забавным (Humorous)
    4. Простым (Humble)

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

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

    Сообщение об ошибке делают полезным три фактора:

    • Заметное ли оно?
    • Объясняет ли оно, что пошло не так?
    • Помогает ли оно пользователю исправить ошибку?

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

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

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

    «Оох! Винстон очень круто одевается. Однако сейчас он, кажется, надел что-то неподходящее (как и страница, которую вы ищете). Давайте поможем ему выбрать что-то другое!»

    У Yahoo! Есть отличный пример использования юмора при подтверждении формы:

    «Вы правда из будущего??»

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

    Как насчет построчной проверки?

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

    «Вы можете использовать буквы, числа и точки»
    «Пожалуйста, введите от 6 до 30 символов»

    Существуют результаты достаточно серьезных исследований по построчной проверке. Люк Вроблевски тестировал ее в 2009 году в сравнении с проверкой после нажатия кнопки «Отправить». Хотя примеров образцов в ходе исследования было не так много, результаты для построчной проверки были таковы:

    • На 22% больше успешно заполненных форм,
    • На 22% меньше ошибок,
    • На 31% увеличилась удовлетворенность пользователей,
    • На 42% сократилось время заполнения,
    • На 47% сократилось число фиксаций взгляда.

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

    Хороший пример построчной проверки сайта booking.com:

    «Мы пришлем сюда подтверждение бронирования и гид по Таллину!»

    Как отслеживать ошибки с помощью Google Analytics

    Тим Лейтон-Бойс из CXFocus не так давно говорил в своем блоге об одном из самых его любимых отчетов GA:

    «Один из самых моих любимых отчетов — это стандартный отчет, которому многие не придают значения: Конверсия > Цели > Обратный путь к цели. Я использую его для отслеживания ошибок.

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

    Обратный путь к цели

    Также можно использовать скрипты для отслеживания ошибок JavaScript на вашей странице, а затем добавить их в отслеживание событий в Google Analytics. Search

    Engine Watch объясняют, как устанавливать отслеживание событий для выявления ошибок в заполнении форм:

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

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

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

    Как сделать сообщения об ошибках доступными

    Перевод “How to make error messages accessible” Hidde de Vries

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

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

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

    Да, это можно запрограммировать

    Прежде чем продолжить, небольшое замечание касательно JavaScript.

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

    Должны ли “доступные” веб-формы избегать JavaScript? Напротив. Нужно использовать его возможности. В сочетании с “серверным” подходом это гарантирует лучший из возможных результат.

    Нет смысла повторять: старые-добрые HTML элементы — ключевой фактор в доступности форм. В статье я коснусь техник, связанных с ARIA, но запомните: первое правило ARIA — не использовать ARIA. Другими словами, если вы можете обойтись возможностями HTML, ARIA не нужно. Исключения касаются решений за пределами HTML, и генерируемые сообщения об ошибках — один из таких случаев. Тем не менее, обратите внимание, HTML5 имеет нативные инструменты для работы с таким функционалом. Если их достаточно для решения ваших задач, то ARIA-атрибуты, описанные в статье, не понадобятся. Изучите также constraint validation API, оно позволяет кастомизировать сообщения.

    Указываем на поле с ошибкой

    Полю формы, заполненному неверно, можно применить атрибут aria-invalid . Убедитесь, чтобы программа следила за изменением значения этого поля и в нужным момент удаляла атрибут.

    Кстати, это еще и удобная возможность выделить элемент визуально:

    Добавление/удаление aria-invalid — способ сообщить об ошибке пользователям скринридеров. Атрибут обрабатывается устройствами с JAWS, NVDA и VoiceOver.

    Доставляем сообщение об ошибке

    Когда программа определяет неправильно заполненное поле, на страницу добавляется сообщение об ошибке. Убедитесь, что его просто увидеть: используйте для выделения цвета, иконки, границы. Хорошей практикой может считаться прямое указание в тексте — “Ошибка”, с которого начинается сообщение.

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

    Существует два относительно эквивалентных способа сделать это. Оба — через ARIA-атрибуты: live regions ( aria-live ) и role=»alert» . Они добавляют в элемент в “живую область”, изменения внутри которой отслеживаются скринридерами. Появление/изменения контента — как раз такой случай. Обратите внимание, в этом случае элемент должен быть частью DOM уже на момент загрузки документа. Атрибуты обрабатываются VoiceOver и большинством версий JAWS и NVDA.

    Работает это следующим образом:

    • Пользователь неправильно заполняет поле №1 и переходит к полю №2;
    • Программа обнаруживает ошибку, прочитывает сообщение об ошибке (либо указывает на нее в виде большого красного сообщения на экране);
    • Тем временем пользователь находится на поле №2 и сам выбирает, вернуться к полю №1 сейчас или позже.

    Live region

    Чтобы сделать элемент частью live region, добавьте ему атрибут aria-live . Он принимает несколько значений. Значения указывают синтезатору, когда озвучить содержимое нового контента: сразу или нет. В нашем случае сообщение должно быть зачитано сразу, поэтому используем aria-live=»assertive» :

    Теперь мы отслеживаем некорректное заполнение полей, но необходимо предусмотреть для них и обратное поведение. Если содержимое поля изменилось и оно валидно, сообщение об ошибке должно быть удалено. Другими словами нам нужно, чтобы live region-элементы могли реагировать как на возникновение, так и исчезновение ошибок. Добиться этого позволяет атрибут aria-relevant :

    Если же мы хотим, чтобы при изменениях внутри элемента зачитывалось все его содержимое, используем атрибут aria-atomic . Значение по умолчанию — true , это значит, что при любом изменении синтезатор заново прочтет элемент целиком (а не только изменившийся фрагмент). Какое значение выбрать — вопрос каждого конкретного случая. Так, если сообщение об ошибке соотносится с определенным полем для валидации, использовать aria-atomic=»true» имеет смысл. Если же “живую область” составляет вся форма целиком, это будет уже излишним.

    role=»alert»

    Альтернатива live region — атрибут role=»alert» , если его присвоить непосредственно сообщению об ошибке.

    Атрибут задает элементу поведение, как если бы он содержал aria-live=»assertive» и aria-atomic=»true» .

    Управление фокусом

    Когда добавляем сообщение об ошибке

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

    Перехват сабмита при наличии ошибок

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

    Обратите внимание, такой подход потенциально конфликтен c aria-live=»assertive» , так как live regions буду зачитаны синтезатором до списка ошибок. Поэтому имеет смысл выбрать только одну из указанных техник.

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

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

    Заключение

    В статье я говорил о трех факторах доступности при создании сообщений об ошибках:

    • указывайте на содержащие ошибки поля при помощи атрибута aria-invalid ;
    • сообщайте о возникновении ошибки, добавляя их в live region-элементы, либо с помощью атрибута role=»alert» для самого сообщения
    • убедитесь, что содержание ошибок и то, как их можно исправить, описано доступным и понятным языком

    Моя благодарность Anneke и Matijs за редактуру и Krijn за комментарии и замечания.

    ошибки.ru

    Вы здесь

    Скрипт отправки сообщений об ошибках

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

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

    Пришлось разрабатывать свой скрипт. Как оказалось, все не так-то просто. Помогли уроки JavaScript, ну и, конечно же, Google с Яндексом. В итоге, при сложении нескольких найденных блоков скрипта и почерпнутых из учебника знаний получился вполне рабочий модуль для проверки ошибок на сайте. Для его работы необходима поддержка PHP на хостинге.

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

    Модуль состоит из четырех файлов: mistakes.js, mistakes.css, mistakes.php и overlay.png.
    Скачать можно отсюда.

    Чтобы его подключить, нужно поместить эти файлы в директорию своего сайта, например в папку «mistakes» и на всех страницах сайта между тегами «head» вставить две строки:

    При этом после src=»http://www.mistakes.ru/script/%3C/strong%3E%20%D0%B8%20%3Cstrong%3Ehref=» нужно прописать путь к файлу mistakes.js и mistakes.css соответственно.

    Файл mistakes.js. В этом файле нужно изменить значение переменной misphploc (то, что между кавычками «») на путь к файлу mistakes.php.

    Файл mistakes.php.
    Здесь нужно изменить значение нескольких переменных:
    $title — заголовок сообщения,
    $to, — email, на который будут отправляться сообщения,
    $mymail — email, от кого пришло сообщение.

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

    На сайте работает система проверки ошибок. Обнаружив неточность в тексте, выделите ее и нажмите Ctrl + Enter.

    Также открыть окошко отправки сообщения можно, кликнув по ссылке:

    Исходная кодировка скрипта windows-1251. Если ваш сайт работает на utf-8, то создайте в папке со скриптом файл .htaccess и добавьте в нем строку:

    Также вам скорее всего нужно будет переформатировать в utf-8 файл mistakes.js

    Если вас по каким-либо причинам не устраивает последняя версия, попробуйте предыдущую — 3.3. mistakes3.3.zip (zip архив 6Kb).

    Успешной вам борьбы с опечатками)) Вопросы и пожелания оставляйте в комментариях.

    Илон Маск рекомендует:  Алгоpитм поpазpядной цифpовой соpтиpовки
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL