Сообщение говорит об ошибке

From Wikipedia, the free encyclopedia

(Redirected from Error Message)

An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with graphical user interfaces, error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, to indicate that a desired operation has failed, or to relay important warnings (such as warning a computer user that they are almost out of hard disk space). Error messages are seen widely throughout computing, and are part of every operating system or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human–computer interaction.^[1]

Common error messages[edit]

The following error messages are commonly seen by modern computer users:^{[citation needed]}

Access denied

This error occurs if the user doesn’t have privileges to a file, or if it has been locked by some program or user.

Device not ready

This error most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving this disk.

File not found

The file concerned may have been damaged, moved, deleted, or a bug may have caused the error. Alternatively, the file simply might not exist, or the user has mistyped its name. This is most commonly seen on the internet with outdated links to web pages that no longer exist. On a local computer, this is more frequent on command line interfaces than on graphical user interfaces where files are presented iconically and users do not type file names.

Low Disk Space

This error occurs when the hard drive is (nearly) full. To fix this, the user should close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.

Out of memory

This error occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or install more memory.

[program name] has stopped working.

This message and similar ones are displayed by several operating systems when program causes a general protection fault or invalid page fault.

Notable error messages[edit]

• Abort, Retry, Fail? — A notoriously confusing error message seen in MS-DOS

  

  An example of an Error message .vbs script

• Bad command or file name — Another notoriously common and confusing error message seen in MS-DOS
• The Blue Screen of Death — On Microsoft Windows and ReactOS operating systems, this screen appears when Windows or ReactOS can no longer run because of a severe error.^[2] It is roughly analogous to a kernel panic on Linux, Unix, or macOS.
• Can’t extend — an error message from Acorn DFS. DFS stores files in non-fragmented contiguous disk space, this error is caused when trying to extend an open random-access file into space that is already occupied by another file.
• Guru Meditation — an error message from the Commodore Amiga, roughly analogous to a kernel panic or BSOD, also adopted by more recent products such as VirtualBox.
• HTTP 404 — A file not found error seen on the World Wide Web, usually resulting from a link to a page that has been moved or deleted, or a mistyped URL
• lp0 on fire — A Unix warning that the printer may be «on fire», literally or not
• Not a typewriter — A Unix error message that is confusing due to its now obsolete use of the word «typewriter», and which is sometimes output when the nature of the error is seemingly entirely different
• PC LOAD LETTER — An error on several HP laser printers that simply asked the user to add «Letter» size paper in a confusing way^[3]
• SYNTAX ERROR — Seen on many computer systems when the received instructions are in a format they don’t understand
• HTTP 504 — An error found on the World Wide Web stating that a gateway timeout occurred in the internet link.
• Error 1603 — An error that states that a problem during installation of a computer program, this error particularly occurs on Windows computer systems.
• <application name> has stopped — An error message commonly found on Android devices, which states a current running application unexpectedly stops working or crashes.
• Success — one of the error messages (in this instance, POSIX) that occurs when the program has detected an error condition, yet the actual error message printing routine relies on C library to print the error reported by the operating system (in this case, errno.h), while the underlying system calls have succeeded and report no errors (in this case, errno == 0). This is a form of sloppy error handling that is particularly confusing for the user.
• [Connection Time Out Error Mac] — Error occurs on Mac systems when it takes more time to connect wireless networks.

Fail pets[edit]

With the rise of Web 2.0 services such as Twitter, end-user facing error messages such as HTTP 404 and HTTP 500 started to be displayed with whimsical characters, termed Fail Pets or Error Mascots. The term «Fail Pet» was coined, or at least first used in print, by Mozilla Engineer Fred Wenzel in a post on his blog entitled «Why Wikipedia might need a fail-pet — and why Mozilla does not.»^[4] Dr. Sean Rintel argues that error messages are a critical strategic moment in brand awareness and loyalty. Fail pets are of interest to marketers because they can result in brand recognition (especially through earned media). «However, that same recognition carries the danger of highlighting service failure.»^[5] The most famous fail pet is Twitter’s Fail Whale (see Twitter service outages). Other fail pets include:

• Ars Technica: Moon Shark (March 3, 2013)
• FarmVille on Facebook: Sad cow.
• GitHub: Octocat
• Google: Broken robot (March 2, 2011)
• iCloud: Cloud with Apple System 7 emoticon-style face and a magnifying glass
• Macintosh: Sad Mac
• Palliser Furniture: Between the cushions (January 31, 2018)
• Tumblr: Tumbeasts (January 25, 2011)
• Twitter: Fail Whale / Twitter Robot (July 30, 2008)
• YouTube: Televisions (on main site), light static inside video window (embedded video)
• Cartoon Network: BMO [Asia]: Domo
• Google Chrome: T-Rex
• Patreon: Red fox with a helmet floating in space
• VK: Sad Vkontakte dog
• Scratch: Giga scratching his head

Message format[edit]

The form that error messages take varies between operating systems and programs.

Error messages on hardware devices, like computer peripherals, may take the form of dedicated lights indicating an error condition, a brief code that needs to be interpreted using a look-up sheet or a manual, or via a more detailed message on a display.

On computers, error messages may take the form of text printed to a console, or they may be presented as part of a graphical user interface. Error messages are often presented as a dialog box, which makes them cause a following mode error in the user interaction. In many cases the original error can be avoided by error prevention techniques. Instead of raising an error message the system design should have avoided the conditions that caused the error.^[6]

While various graphical user interfaces have different conventions for displaying error messages, several techniques have become common:

• A dialog box, or pop-up message, appears in a window on the screen, blocking further interaction with the computer until it is acknowledged. On Mac OS X, sheets are a form of dialog box that are attached to a specific window.
• Notification icons appear to notify a user about a condition without interrupting their work. On Windows, notification icons appear in the System Tray. On Mac OS X, notification icons may appear in the menu bar, or may take the form of an application’s icon «bouncing» in the Dock. The GNOME user interface for Unix systems can display notification icons in a panel.
• Minor errors may be displayed in a status bar, a small portion of an application’s window that can display brief messages to the user.

The three main factors^[7] that influence the design of error messages are technical limitations, the amount of information to be presented, and what kind of user input is required.

Some systems have technical limitations that may constrain the amount of information an error message can contain. For example, a printer with a sixteen-character alphanumeric display can only show a very limited amount of information at once, so it may need to display very terse error messages. Even with computer monitors, the programmer must consider the smallest monitor that a user might reasonably use, and ensure that any error messages will fit on that screen.

The nature of the error determines the amount of information required to effectively convey the error message. A complex issue may require a more detailed error message in order to adequately inform the user of the problem.

Security[edit]

When designing error messages, software designers should take care to avoid creating security vulnerabilities. The designer should give the user enough information to make an intelligent decision, but not so much information that the user is overwhelmed or confused. Extraneous information may be hidden by default or placed in a separate location. Error message should not expose information that can be exploited by a cracker to obtain information that is otherwise difficult to obtain. Examples are systems which may show either «invalid user» or «invalid password» depending on which is incorrect, and the error page in the web server IIS 5.0 which provides a complete technical description of the error including a source code fragment.

See also[edit]

• Alert dialog box
• Human–computer interaction
• Interaction design
• Usability
• User error
• User interface design
• Exception handling

References[edit]

External links[edit]

• A more useful 404 (A List Apart)
• Avoid being embarrassed by your error messages (UX Matters)
• Oops! I ruined your life. 🙂 (Cooper Journal) Archived 2014-08-25 at the Wayback Machine

From Wikipedia, the free encyclopedia

(Redirected from Error Message)

An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with graphical user interfaces, error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, to indicate that a desired operation has failed, or to relay important warnings (such as warning a computer user that they are almost out of hard disk space). Error messages are seen widely throughout computing, and are part of every operating system or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human–computer interaction.^[1]

Common error messages[edit]

The following error messages are commonly seen by modern computer users:^{[citation needed]}

Access denied

This error occurs if the user doesn’t have privileges to a file, or if it has been locked by some program or user.

Device not ready

This error most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving this disk.

File not found

The file concerned may have been damaged, moved, deleted, or a bug may have caused the error. Alternatively, the file simply might not exist, or the user has mistyped its name. This is most commonly seen on the internet with outdated links to web pages that no longer exist. On a local computer, this is more frequent on command line interfaces than on graphical user interfaces where files are presented iconically and users do not type file names.

Low Disk Space

This error occurs when the hard drive is (nearly) full. To fix this, the user should close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.

Out of memory

This error occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or install more memory.

[program name] has stopped working.

This message and similar ones are displayed by several operating systems when program causes a general protection fault or invalid page fault.

Notable error messages[edit]

• Abort, Retry, Fail? — A notoriously confusing error message seen in MS-DOS

  

  An example of an Error message .vbs script

• Bad command or file name — Another notoriously common and confusing error message seen in MS-DOS
• The Blue Screen of Death — On Microsoft Windows and ReactOS operating systems, this screen appears when Windows or ReactOS can no longer run because of a severe error.^[2] It is roughly analogous to a kernel panic on Linux, Unix, or macOS.
• Can’t extend — an error message from Acorn DFS. DFS stores files in non-fragmented contiguous disk space, this error is caused when trying to extend an open random-access file into space that is already occupied by another file.
• Guru Meditation — an error message from the Commodore Amiga, roughly analogous to a kernel panic or BSOD, also adopted by more recent products such as VirtualBox.
• HTTP 404 — A file not found error seen on the World Wide Web, usually resulting from a link to a page that has been moved or deleted, or a mistyped URL
• lp0 on fire — A Unix warning that the printer may be «on fire», literally or not
• Not a typewriter — A Unix error message that is confusing due to its now obsolete use of the word «typewriter», and which is sometimes output when the nature of the error is seemingly entirely different
• PC LOAD LETTER — An error on several HP laser printers that simply asked the user to add «Letter» size paper in a confusing way^[3]
• SYNTAX ERROR — Seen on many computer systems when the received instructions are in a format they don’t understand
• HTTP 504 — An error found on the World Wide Web stating that a gateway timeout occurred in the internet link.
• Error 1603 — An error that states that a problem during installation of a computer program, this error particularly occurs on Windows computer systems.
• <application name> has stopped — An error message commonly found on Android devices, which states a current running application unexpectedly stops working or crashes.
• Success — one of the error messages (in this instance, POSIX) that occurs when the program has detected an error condition, yet the actual error message printing routine relies on C library to print the error reported by the operating system (in this case, errno.h), while the underlying system calls have succeeded and report no errors (in this case, errno == 0). This is a form of sloppy error handling that is particularly confusing for the user.
• [Connection Time Out Error Mac] — Error occurs on Mac systems when it takes more time to connect wireless networks.

Fail pets[edit]

With the rise of Web 2.0 services such as Twitter, end-user facing error messages such as HTTP 404 and HTTP 500 started to be displayed with whimsical characters, termed Fail Pets or Error Mascots. The term «Fail Pet» was coined, or at least first used in print, by Mozilla Engineer Fred Wenzel in a post on his blog entitled «Why Wikipedia might need a fail-pet — and why Mozilla does not.»^[4] Dr. Sean Rintel argues that error messages are a critical strategic moment in brand awareness and loyalty. Fail pets are of interest to marketers because they can result in brand recognition (especially through earned media). «However, that same recognition carries the danger of highlighting service failure.»^[5] The most famous fail pet is Twitter’s Fail Whale (see Twitter service outages). Other fail pets include:

• Ars Technica: Moon Shark (March 3, 2013)
• FarmVille on Facebook: Sad cow.
• GitHub: Octocat
• Google: Broken robot (March 2, 2011)
• iCloud: Cloud with Apple System 7 emoticon-style face and a magnifying glass
• Macintosh: Sad Mac
• Palliser Furniture: Between the cushions (January 31, 2018)
• Tumblr: Tumbeasts (January 25, 2011)
• Twitter: Fail Whale / Twitter Robot (July 30, 2008)
• YouTube: Televisions (on main site), light static inside video window (embedded video)
• Cartoon Network: BMO [Asia]: Domo
• Google Chrome: T-Rex
• Patreon: Red fox with a helmet floating in space
• VK: Sad Vkontakte dog
• Scratch: Giga scratching his head

Message format[edit]

The form that error messages take varies between operating systems and programs.

Error messages on hardware devices, like computer peripherals, may take the form of dedicated lights indicating an error condition, a brief code that needs to be interpreted using a look-up sheet or a manual, or via a more detailed message on a display.

On computers, error messages may take the form of text printed to a console, or they may be presented as part of a graphical user interface. Error messages are often presented as a dialog box, which makes them cause a following mode error in the user interaction. In many cases the original error can be avoided by error prevention techniques. Instead of raising an error message the system design should have avoided the conditions that caused the error.^[6]

While various graphical user interfaces have different conventions for displaying error messages, several techniques have become common:

• A dialog box, or pop-up message, appears in a window on the screen, blocking further interaction with the computer until it is acknowledged. On Mac OS X, sheets are a form of dialog box that are attached to a specific window.
• Notification icons appear to notify a user about a condition without interrupting their work. On Windows, notification icons appear in the System Tray. On Mac OS X, notification icons may appear in the menu bar, or may take the form of an application’s icon «bouncing» in the Dock. The GNOME user interface for Unix systems can display notification icons in a panel.
• Minor errors may be displayed in a status bar, a small portion of an application’s window that can display brief messages to the user.

The three main factors^[7] that influence the design of error messages are technical limitations, the amount of information to be presented, and what kind of user input is required.

Some systems have technical limitations that may constrain the amount of information an error message can contain. For example, a printer with a sixteen-character alphanumeric display can only show a very limited amount of information at once, so it may need to display very terse error messages. Even with computer monitors, the programmer must consider the smallest monitor that a user might reasonably use, and ensure that any error messages will fit on that screen.

The nature of the error determines the amount of information required to effectively convey the error message. A complex issue may require a more detailed error message in order to adequately inform the user of the problem.

Security[edit]

When designing error messages, software designers should take care to avoid creating security vulnerabilities. The designer should give the user enough information to make an intelligent decision, but not so much information that the user is overwhelmed or confused. Extraneous information may be hidden by default or placed in a separate location. Error message should not expose information that can be exploited by a cracker to obtain information that is otherwise difficult to obtain. Examples are systems which may show either «invalid user» or «invalid password» depending on which is incorrect, and the error page in the web server IIS 5.0 which provides a complete technical description of the error including a source code fragment.

See also[edit]

• Alert dialog box
• Human–computer interaction
• Interaction design
• Usability
• User error
• User interface design
• Exception handling

References[edit]

External links[edit]

• A more useful 404 (A List Apart)
• Avoid being embarrassed by your error messages (UX Matters)
• Oops! I ruined your life. 🙂 (Cooper Journal) Archived 2014-08-25 at the Wayback Machine

Автор: Майкл Болтон

Перевод: портал software-testing.ru

Оригинал статьи: http://www.developsense.com/essays/AReviewOfErrorMessages.html

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

Начальные знания о сообщениях об ошибке

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

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

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

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

При этом не стоит полагаться и на операционную систему. Удивительно, но команды DOS COPY и XCOPY до сих пор не проводят проверку на наличие свободного места на диске перед началом копирования файлов; вместо этого копирование начинается “вслепую” с надеждой на то, что места будет достаточно. Windows ничуть не лучше, эта система тоже не проверяет диск на наличие свободного места перед копированием файлов. Хуже того, если вы одновременно копируете несколько файлов, Windows прерывает процесс копирования после обнаружения первой ошибки и “забывает”, какие файлы были выделены для копирования.

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

 Как выглядит корректно составленное сообщение об ошибке?

Сообщение об ошибке должно:

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

Оно не должно:

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

Хороший пример

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

«Система ATS потеряла связь с принтером. Для решения проблемы убедитесь, что принтер включен, и попробуйте запустить печать снова. Если напечатать документ не удается, убедитесь, что оба конца кабеля, соединяющего компьютер с принтером, надежно соединены с устройствами, и попробуйте снова запустить печать. Если и в этом случае проблема не устранена, свяжитесь с Джо Грантом по номеру (212) 555-1212 и сообщите ему, что программа выдает ошибку ATSPR35 в строке 31, модуль PRNFNC»

Это сообщение программы по подбору персонала (называется «Система ATS»), созданной независимым разработчиком для кадрового агентства в 1988. Сообщение выглядит почти так, как я описал выше. Существенным отличием является то, что оно не имеет привычный вид окна Windows, потому что это сообщение из программы DOS. Я упоминаю об этом, потому что это сообщение было составлено во времена, когда объем памяти ограничивался 640 Кб. У пользователей тогда не было большого опыта работы с компьютером, но даже если бы они были экспертами в этой области, все равно сообщение было бы полезным.

Давайте сравним это сообщение с требованиями, предложенными выше:

• Сообщение совершенно четко идентифицирует программу. Более того, строка заголовка идентифицирует тип ошибки.
• В сообщении сказано о том, что программа потеряла связь с принтером. В сообщении не говорится «невозможно напечатать», или «LPT1: Ошибка», или любой другой малоинформативный текст, скопированный из операционной системы. Сообщения об ошибке большинства операционных систем очень лаконичны и обычно для пользователя бесполезны. А это сообщение составлено так, что его может понять обычный пользователь.
• В сообщении пользователю предлагаются действия, которые он способен выполнить, независимо от уровня или опыта владения программой. Здесь не высказываются догадки о причине ошибки. Предложенные действия располагаются от простого к более сложному, а причины – от более вероятных к менее вероятным. Отчасти здесь автору программы повезло – далеко не всегда самые распространенные ошибки проще всего исправить.
• Программа не предлагает действий, которые будут пустой тратой времени. («Попробуйте перезапустить программу», или еще хуже, «Попробуйте переустановить приложение».)
• Текст сообщения тщательно составлен. Важен каждый пункт сообщения. Нет бесполезных рекомендаций. Не предлагается искать причину сбоя в другом приложении. Вся информация точная и полезная.
• Самое главное, в сообщении есть полезная техническая информация и для пользователя, и для сотрудника техподдержки, и для разработчика. Если ошибка содержится в коде, сообщение указывает программисту, где именно следует искать ошибку и тип ошибки. Немаловажный плюс – указание реального имени человека. Приятнее иметь дело с конкретным человеком, чем с абстрактной организацией, наличие имени программиста говорит об ответственности за свою работу.

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

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

 «Невозможно загрузить список новых групп. Произошла ошибка»

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

К этому сообщению у меня вообще нет комментариев.

К этому тоже. Хотя оно выглядит не таким грозным как предыдущее.

 «Интерфейс передачи сообщений вернул неизвестную ошибку. Если проблема повторяется, перезапустите Outlook»

Вам известно больше, чем вы сообщаете, и вы что-то скрываете? И кстати, как именно может помочь перезапуск Outlook?

 «Переключение из режима Internet Only E-mail Service в режим Corporate or Workgroup E-mail Service может быть несовместимо с существующими приложениями»

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

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

 «Возможно». Компонент занят или отсутствует, или и то и другое? Если компонент используется, то какой именно компонент? Файл? Если так, можно узнать имя файла?

«Действие не может быть выполнено. Действие не может быть выполнено».

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

 «Невозможно найти файл cuecard.hlp. Хотите найти файл вручную?»

Нет, не хочу. Я хочу, чтобы вы его нашли.

«Невозможно найти файл cuecard.hlp. Проверьте наличие файла на вашем диске. Если файл не будет найден, переустановите его».

Может, все-таки поищете, нет? Честно говоря, я не помню ситуацию, при которой я получил это сообщение, соответственно не помню и программу, которая его вывела. Тем не менее, я помню, что и тогда мне было непонятно, что мне следует переустановить.

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

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

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

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

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

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

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

Обсудить в форуме

Перевод краткого руководства от UX-писателя BBC Эми Лик.

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

Определите, с какой ошибкой столкнулся пользователь

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

Структура текста

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

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

Бывает, система не может указать, что именно произошло.

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

Пишите коротко и ясно

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

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

Системная ошибка

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

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

Ошибка пользователя

Иногда ошибки появляются по вине пользователя. Но сообщить об этом можно мягко и без осуждения.

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

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

Используйте правильный тон

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

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

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

Что случится, если нажать на кнопку

Для устранения некоторых ошибок могут потребоваться СТА-кнопка или ссылка. Иногда бывает нужна кнопка отмены.

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

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

Время и место

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

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

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

Ключевые рекомендации

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

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

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

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

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

Юзабилити: чего стоит избегать в сообщениях об ошибках?

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

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

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

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

Приложение Booking.com делает прошедшие даты неактивными для выбора

Профилактика ошибок пользователей при разработке интерфейсов

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

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

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

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

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

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

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

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

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

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

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

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

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

«Этот email уже зарегистрирован. Хотите войти или восстановить свой пароль?»

Валидация лид-форм — полное руководство

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

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

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

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

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

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

Экран приложения Spotify просто заявляет о том, что «произошла ошибка», и не дает никаких дальнейших рекомендаций пользователю

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

«Сервер c таким именем хоста не может быть найден. Повторите попытку»

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

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

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

«Не удается подключиться к этой сети. Вы должны подключиться к Wi-Fi сети, чтобы управлять iTunes или Apple TV»

Юзабилити: чего стоит избегать в сообщениях об ошибках?

Используйте изображения и юмор

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

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

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

А вы фанат пунктуации! Увы, имена пользователей не могут содержать многоточия

Тем не менее, юмор не всегда может быть уместен. Это зависит от того, насколько серьезная проблема. Например, юмор вполне можно использовать для констатации такой простой проблемы как «Ошибка 404. Страница не найдена.» Однако когда пользователь теряет значительное количество времени в результате сбоя, говорить «Опаньки!» совершенно неуместно.

«Опаньки! Возникла ошибка, и мы не смогли опубликовать эту историю»

Итак, чтобы создать идеальную страницу ошибки, стоит учесть следующее:

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

Высоких вам конверсий!

По материалам: smashingmagazine.com

06-10-2016