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

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

Тем не менее в одном из небольших проектов мы (команда разработчиков) решили пойти чуть-чуть дальше и вне?ти небольшое, но довольно значительное в концептуальном плане изменение. Было прин?то решение полно?тью избавит?? от пон?ти? “ошибка”. Ведь как уже многими было показано и доказано, в большин?тве ?лучаев пользователи во?принимают “ошибки” программы как ?вои ?об?твенные, хот? в реально?ти дело об?тоит как раз наоборот – «ошибка» е?ть признак некаче?твенной программы. Само пон?тие “ошибка” в?егда подразумевает наличие кого-то виновного в ней.

Вкратце изменение заключало?ь в замене пон?ти? “?ообщени? об ошибке” на пон?тие “проблема”. Проблема - пон?тие до?таточно нейтральное, предполагающее уча?тие в ней не?кольких ?торон. В каче?тве о?новы дл? решени? был выбран пример из книги ?.Купера „About Face“ . Выгл?дит в?ё ?то примерно так:

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

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

В защиту ?видетель?твует также ?ама и?тори? внедрени? программы ? «проблемными окнами» внутри. Дело в том, что по?ле “выхода” программы мы долгое врем? ничего не ?лышали об ?тих окнах от пользователей. Мы ?очли ?то признаком того, что пока ни одной «проблемы» ещё не возникало. Однако через некоторое врем? мы были при?тно удивлены, опро?ив пользователей и узнав, что они уже в?тречали?ь ? проблемами, но при ?том у?пешно решали их ?ами, руковод?тву??ь ?одержащей?? в ней информацией.

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